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PREFACE 


This  document  was  prepared  by  the  University  of  Houston,  Houston,  Texas, 
on  Air  Force  Contract  No.  F33615-80~C-1095,  entitled  "The  Remote  Link  Unit  -  A 
Demonstration  of  Operational  Performance.” 

The  work  was  administered  under  the  direction  of  the  Information  Transfer 
■c  Group,  Information  Processing  Technology  Branch,  System  Avionics  Division  of 

the  Avionics  Laboratory,  under  Project  2003,  "Avionic  System  Design 
Technology,"  Task  08,  "Multiplex  and  Information  Transfer  Technology,"  Work 
^  Unit  07,  "Remote  Link  Unit  Demonstration."  The  work  was  performed  during  the 

period  1  April  1980  to  31  December  1980  and  this  report  was  submitted  in 
August  1981.  The  Air  Force  Project  Engineer  was  Philip  C.  Goldman 
(AFWAL/AAAT-3) . 

The  work  is  a  continuation  of  a  previous  feasibility  study  entitled,  "The 
Remote  Link  Unit:  An  Advanced  Remote  Terminal  for  M1L-STD-1553A."  The 
results  of  this  study  are  documented  in  a  technical  report  entitled,  "Remote 
Link  Unit  Functional  Design:  An  Advanced  Remote  Terminal  for  MIL-STD-1553B," 
which  was  published  as  AFAL-TR-79-1176,  AD-A080126.  An  add-on  to  this  pre¬ 
vious  study  resulted  in  a  second  technical  report  entitled,  "The  Remote  Link 
Unit:  Applications  to  the  Design  for  Repair  Methodology  Program,"  published 
as  AFWAL-TR-80-1033,  AD-A086126. 

This  report  summarizes  the  design,  development,  and  testing  accomplished 
under  the  contracted  work.  The  Principal  Investigator  and  Program  Manager  was 
Dr.  Carlos  J.  Tavora.  Drs.  John  Glover,  Jr.  and  Miles  A.  Smlther  were  Co- 
Investigators.  Dr.  Tavora  was  responsible  for  the  system  architecture  and 
modularization  of  the  design.  Dr.  Glover  supervised  the  design  of  the  soft¬ 
ware  for  the  Link  Manager  Simulator  and  the  Link  Module.  He  was  assisted  by 
Messrs.  Hao-Cheng  Hsla,  William  C.  Law,  and  Parmanand  Balsaver.  Dr.  Smlther 
was  assisted  by  Mr.  Tzer-Tsan  Lin  in  the  design  of  the  Interface  Configuration 
Adapter.  Mr.  H.  Mitchell  Collins  was  in  charge  of  the  design  of  the 

•  Electronic  Nameplate  and  the  Nameplate  Interface  Controller. 

This  report  is  organized  in  three  parts:  Part  I  -  Summary,  Part  II  - 

*  User's  Manual,  and  Part  III  -  Design  Manual.  Part  III  is  separated  into  two 

volumes:  Volume  1  is  the  main  body  of  the  Design  Manual,  while  Volume  2 

contains  the  appendices. 


This  is  Volume  1  of  Part  III,  Design  Manual.  It  describes  the  detailed 
hardware  and  software  design  of  the  RLUDS,  and  is  organized  such  that  major 
sections  relate  to  each  functional  subsystem  within  the  RLUDS. 
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SECTION  1 


INTRODUCTION 

\ 

This  document  is  a  design  manual  for  the  Remote  Link  Unit  Demonstration 
System  (RLUDS).  The  Remote  Link  Unit  (RLU)  Is  a  new  design  concept  for  re¬ 
mote  terminals.  This  document  contains  detailed  design  Information  on  the 

RLUDS  Design  and  implementation  of  the  RLUDS  was  performed  for  the  Air 

\ 

Force  Wright  Aeronautical  Laboratories  under  contract  #F33615-80-C-1095. 


1.1  THE  RLU  DEMONSTRATION  UNIT 


V 


'The  RLUDS  described  In  this  design  manual  Is  an  operational  hardware 


breadboard  prototype  that  performs  most  of  the  Important  RLU  function^  The 
RLUDS  Is  not  intended  to  be  a  cos^lete  RLU  -prototype  but  It  demonstrates 
the  most  unique  parts  of  the  RLU.  ^his  effort  has  demonstrated  the  feasi¬ 
bility  of  Implementation  of  the  Link  Module  (LM) ,  the  Interface  Configura¬ 
tion  Adapter  (ICA) ,  the  Electronic  Nameplate  (NP)  and  the  Interface  between 
the  Link  Module  and  the  Link  Manager.  The  Link  Manager  (LMG)  was  simulated 
with  a  PDF-11  computer.  The  extent  of  RLU  Implementation  encompassed  by 
the  demonstration  unit  Is  lllustrated^n  Figure  1.  The  detailed  design  of 
the  RLUDS  Is  based  on  the  functional  deH^gn  described  In  the  document, 
"Remote  Link  Unit  Functional  Design:  An  Advanced  Remote  Terminal  for 
MIL-STD-1553B"  technical  report  AFAL-TR-79-1176.  Jthe  configuration  of  the 
RLUDS  Is  presentec^l^  Figure  2. 

1.2  DESIGN  CONSTRAINTS 


In  order  to  Implement  the  RLUDS  within  a  short  time  span.  It  was  Im- 


Figure  1  RLUDS  Implementation  of  the  RLU 


LINK  MANAGER  (UMG) 
SIMULATOR 


FlRure  2  SLUDS  Configuration 
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perative  to  limit  the  design  effort  to  the  development  of  components  which 
were  nonexistent  and  constituted  critical  elements  for  verification  of  the 
RLU  concepts.  In  order  to  accoimnodate  use  of  off-the-shelf  components,  it 
was  necessary  for  the  RLUDS  design  to  deviate  from  the  RLU  functional  de¬ 
sign  (document  AFAL-TR-79^1176) .  Some  of  the  required  deviations  are 
Identified  In  the  statement  of  work  for  the  RLUDS.  Other  deviations  have 
been  Identified  In  the  process  of  designing  the  demonstration  system.  In 
each  case,  a  deviation  to  the  functional  design  was  allowed  when  It  related 
a  change  that  did  not  alter  the  RLU  concept  to  be  evaluated,  but  rather 
represented  a  design  scaling  of  electrical  or  timing  dimensions.  The  most 
significant  difference  between  the  RLU  functional  design  and  the  RLUDS 
stems  from  the  use  of  an  8  bit  microprocessor  for  implementation  of  the 
Link  Module.  This  selection, which  was  dictated  by  the  available  micropro¬ 
cessor  development  facilities  at  the  University  of  Houston, led  to  an  8-blt 
LM  Internal  bus  Instead  of  the  16-bit  bus  described  in  the  functional  de¬ 
sign.  Use  of  the  8-blt  LM  Internal  bus  has  caused  corresponding  dimensional 
changes  In  the  Interface  Configuration  Adapter,  the  Nameplate  Interface 
Controller  and  the  Shared  Memory. 


1.3  TEST  PROCEDURE 

A  test  plan  that  outlines  the  approach  used  to  demonstrate  the  oper¬ 
ational  performance  of  the  RLU  Is  presented  In  the  document  entitled,  "A 
Test  Plan  for  the  Remote  Link  Unit  Demonstration  System."  This  test  plan 
describes  a  three  part  test  procedure  that  demonstrates  the  operation  of  the 
Interface  Configuration  Adapter,  the  Subsystem  Information  channel  and  the 
Remote  Link  Unit. 


3 


1.4  ORGANIZATION  OF  THE  MANUAL 


This  manual  has  been  organized  In  a  manner  that  simplifies  the  docu¬ 
mentation  of  the  KLUDS  design.  Sections  2  through  5  describe  the  major 
RLUDS  components  In  terms  of  the  theory  of  operation,  the  hardware  design, 
the  software  design  and  the  test  procedure.  Section  2  describes  the  L Ink 
Module.  Section  3  describes  the  design  of  the  Interface  Configuration 
Adapter.  Section  4  describes  the  Subsystem  Information  channel  which  In¬ 
cludes  the  Nameplate  Interface  Controller,  the  nameplate  bus  and  the 
Electronic  Nameplate.  Section  5  describes  the  Link  Manager  simulator  and 
the  software  required  to  support  the  RLUDS  demonstration.  Section  6 
describes  the  serial  and  synchro  subsystems  used  In  the  KLU  demonstration. 
The  detailed  hardware  diagrams  and  parts  lists  are  contained  In  Appendix 
fi  .  The  detailed  software  description  is  presented  in  Appendix  C  . 
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SECTION  2 


LINK  MODULE 

2.1  DESIGN  PHILOSOPHY 

2.1.1  DESCRIPTION 

The  Link  Module  (LM)  consists  of  a  parallel  bus  structure  with 
Motorola  6800  Processor,  PROM,  RAM,  and  three  separate  Interfaces  as  shown 
in  Figure  3 .  Each  Interface  connects  to  the  connon  bus  structure  of  the 
processor  chassis.  There  Is  a  Shared  Memory  (SM)  Interface  to  the  Link 
Manager  (LMG)  through  which  all  conmunlcatlon  between  the  LM  and  the  LMG 
takes  place.  There  Is  a  Nameplate  Interface  Controller  (NIC)  Interface  to 
the  subsystem  nameplates  for  serial  communication  between  the  LM  and  the 
NP's  on  the  Subsystem  Information  Channel  (SIC)  bus.  There  is  a  parallel 
digital  Interface  to  the  Interface  Configuration  Adaptor  (ICA)  for  communl* 
cation  between  the  LM  and  the  ICA. 

2.1.2  DESIGN  PHILOSOPHY 

The  Link  Module  (LM)  is  the  intelligent  link  between  the  Link 
Manager  (LMG)  and  the  subsystems.  It  consists  of  a  processor  with  three 
Interfaces. 

The  following  design  goals  were  established  for  the  Link  Module 

design: 

1)  Minimize  hardware  fabrication. 

2)  Utilize  off-the-shelf  items. 

3)  Concentrate  development  effort  on  conceptual  features  of  the 
RLU  not  yet  demonstrated  as  feasible. 

4)  Provide  built-in  trouble  shooting  capability  through  the  use 
of 
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•  Hodularlzed  enclosures , 
e  Front  panel  status  Indicators,  and 

e  A  software  monitor  debugger. 

2.1.3  IMPLEMENTATION 

The  microprocessor  6800  was  chosen  for  the  LM  Implementation  since 
It  met  the  processing  requirements  and  substantial  hardware  and  software 
development  support  for  this  processor  Is  available  at  the  Digital  Control 
and  Automation  System  Laboratory  at  the  University  of  Houston. 

The  LM  Is  distributed  among  two  chassis  as  shown  In  Figure  4  . 
Except  for  the  ICA  which  Is  housed  In  the  top  chassis  all  other  LM  components 
are  housed  In  the  main  chassis.  The  main  chassis  Is  a  Motorola  chassis  with 
a  card  cage  and  bus  system  that  accepts  a  variety  of  off-the-shelf  modules 
for  the  6800  system. 


2.2  HARDWARE  DESIGN 

2.2.1  LINK  MODULE  HARDWARE  DECOMPOSITION 

The  Link  Module  (LM)  hardware  comprises  two  chassis:  main  chassis 
and  extension  chassis.  The  main  chassis  holds  power  supplies,  card  cage 
with  various  cards  (the  processor,  program  memory,  data  memory.  Shared  Mem¬ 
ory,  Nameplate  Interface  Controller,  bus  connections  to  the  Interface  Con¬ 
figuration  Adaptor),  front  panel  and  back  panel. 

The  extension  chassis  houses  the  ICA  and  mounts  directly  on  top 
of  the  main  chassis  and  contains  3  circuit  boards,  a  front  panel  and  a  back 
panel.  The  ICA  front  panel  displays  ICA  configuration  Information  which  Is 
useful  for  monitoring  the  Interface  operation.  The  back  panel  Is  used  for 
power  and  signal  connections. 
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The  cards  In  the  main  chassis  are  listed  In  Table  1  .  The  chassis 


(Motorola  P/N  M68MMLC)  contains  a  triple  DC  output  power  supply  (+SV,  -<-12V, 
-12V)  and  a  10  slot  card  cage.  Two  additional  voltage  supplies  have  been 
Installed  In  the  main  chassis:  a  dual  DC  output  (+1SV,  -15V)  for  the  ICA, 
and  a  single  DC  output  (+25V)  for  the  NP.  The  CPU  card  (Motorola  P/N 
M68MM01A2)  contains  a  Motorola  6800  eight  bit  processor,  1  MHz  crystal  con¬ 
trolled  clock,  IK  byte  read/write  memory  (not  used  in  the  LM  implementation), 
four  sockets  for  2716  EPROMs  (2K  bytes  each  of  program  memory),  four  eight 
bit  parallel  digital  ports  (not  used  in  the  LM  implementation) ,  and  one 
serial  RS-232C  data  terminal  Interface  (used  by  the  M68MM08A  ROM  for  system 
debugging).  A  program  memory  card  (Motorola  P/N  M68MM04A)  provides  sixteen 
sockets  for  2716  EPROMs  for  32K  bytes  of  additional  program  memory  space. 
Data  memory  is  provided  by  a  Motorola  MEX6816-1HR  which  has  16K  bytes  of 
read/write  memory.  Three  custom  Interface  cards  (SM,  NIC,  FP/ICA)  are  based 
on  Motorola  MEX68USM  universal  interface  cards  which  provide  address  decod¬ 
ing  and  bus  buffering. 

The  extension  chassis  houses  the  ICA.  This  chassis  has  three 
circuit  cards:  a  control/processor  interface  module  and  two  signal  I/O 
Interface  cards  (one  for  each  ICA  group).  The  ICA  extension  chassis  fits 
physically  on  top  of  the  LM  main  chassis. 

A  front  panel  layout  Is  shown  In  Figure  5  .  Located  on  the  front 
panel  are  various  display  Indicators,  facility  to  write  Into  Shared  Memory, 
power  on/off  switch,  and  a  reset  button.  Additionally,  the  extension 
chassis  front  panel  has  various  ICA  status  Indicators. 

The  main  chassis  back  panel  has  the  AC  power  Input,  three  fuses 
(115VAC  to  LM,  +5VDC  to  NP,  +25VDC  to  NP) ,  a  fan  for  air  circulation,  a 
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Table  1 

LINK  MODULE  MAIN  CHASSIS  CARDS 


Slot  # 

Card  # 

Description 

Connectors 

1 

1 

FP  &  ICA 

INTCBL  500  to  Front  Panel 

&  INTCBL  200  to  ICA. 

2 

- 

Empty 

3 

3 

PROM 

None 

4 

4 

RAM 

None 

5 

- 

Empty 

6 

6 

NIC 

INTCBL  300  to  NP. 

7 

- 

ESnpty 

8 

8 

CPU 

INTCBL  400  to  CRT. 

9 

9 

SM 

INTCBL  100  to  UIG. 

10 

_ I _ 

Empty 

connector  to  the  LMG  for  communication  through  Shared  Memory,  a  connector 
to  the  Electronic  Nameplate,  connector  to  a  data  terminal  for  system  de¬ 
bugging,  and  a  toggle  switch  for  choosing  the  restart  vectors  (auto  or 
monitor).  The  extension  chassis  back  panel  has  three  fuses  (+5VDC,  +15VDC, 
-15VDC)  and  a  connector  to  the  subsystem. 

2.2.2  MODULES  AND  ADDRESS  ASSIGNMENTS 

The  address  assignment  for  each  LM  module  Is  shown  on  the  memory 
map  presented  in  Figure  7  which  shows  the  Motorola  M6800  address  space 
of  64K  bytes.  All  addresses  shown  in  this  figure  are  expressed  as  hexa¬ 
decimal  numbers  (base  16).  The  16K  data  memory  Is  In  the  lower  addresses 
from  0004)  to  3FFF,  with  the  IK  byte  on  the  CPU  card  disabled  to  avoid 
address  conflicts.  The  program  memory  card  has  two  Independent  16K  blocks. 
The  first  block  (addresses  4000  to  7FFF)  contains  the  software  tasks  EXEC 
UPDATE,  ISR,  CMDITR,  part  of  NPHND,  and  IC.1HND.  The  second  block  uses  only 
one  quarter  of  Its  address  space  (8800  to  97FF)  and  contains  the  software 
tasks  SMHND  and  the  rest  of  the  NPHND.  The  SM  and  NP  fit  Into  addresses 
8000  to  83FF.  Addresses  8400  to  87PF  are  used  for  parallel  and  serial  I/O 
on  the  CPU  card.  The  ICA  and  front  panel  Interface  modules  fit  Into 
addresses  9800  to  98FF.  The  Motorola  M68MM08A  MICRObug  EOM  monitor  resides 
In  addresses  F800  to  FFFF  (a  back  panel  switch  may  be  used  to  enable  the 
monitor  mode  of  operation) . 

2.2.3  SHARED  MEMORY  INTERFACE  CARD 

The  Link  Manager  (LMG)  and  the  Link  Module  (LM)  perform  all  of 
their  communications  through  a  shared  memory  Interface  consisting  of  256 
bytes  of  read/write  memory.  The  LM  makes  Its  accesses  to  SM  directly. 
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Just  as  It  does  to  any  other  memory  location,  since  the  SM  is  In  the  memory 
space  of  the  LM  (at  addresses  8000  to  80FF) .  The  LMG  which  Is  simulated  on 
a  DEC  PDF  11/70  Interfaces  to  the  LM  Shared  Memory  (SM)  through  a  DEC  DRllC 
board  as  block  diagrammed  In  Figure  8  .  All  transfers  are  single  8-bit 
byte  transfers  and  are  done  with  a  complete  handshake  for  each  byte  using 
three  of  the  four  control  lines  shown  in  Figure  8  . 

The  LMG  Interface  board  has  two  output  control  lines  labeled  CSR0 
and  CSRl.  These  are  used  as  Chip  Select  (CS)  and  Write  Enable  (WE)  respec¬ 
tively  to  the  SM  hardware.  The  LMG  interface  board  has  two  input  control 
lines  labeled  AREQ  and  BREQ.  The  BREQ  line  is  unused,  while  the  AREQ  line 
is  used  for  the  return  handshake  for  all  data  transfers.  The  corresponding 
handshakes  for  read  (RD) ,  write  (WR) ,  and  read-modify-wrlte  (RMW)  are 
diagrammed  in  Figure  9  .  A  complete  handshake  is  performed  for  each  byte 
of  data  transferred  between  the  LM  and  LMG. 

The  SM  address  and  data  buses  are  shared  between  the  LM  and  LMG 
and  thus  cannot  be  accessed  by  both  at  the  same  time.  This  is  resolved  by 
making  the  LMG  accesses  to  SM  by  Direct  Memory  Access  (DMA) .  This  DMA  is 
implemented  by  having  the  LMG  CS  line  act  as  a  halt  request  to  the  LM  6800 
processor.  The  Bus  Available  (BA)  signal  from  the  6800  is  then  used  as  the 
returning  handshake  AREQ  to  the  LMG.  Details  of  this  timing  can  be  seen  In 
Figure  10  . 

RMW  is  a  special  implementation  which  allows  each  side  to  read  a 
data  byte,  modify  the  value,  and  write  the  value  back  without  the  other  side 
being  able  to  access  it  during  this  time.  For  LMG  accesses  this  is  no  prob¬ 
lem  using  the  special  RMW  handshake  shown  in  Figure  9  since  the  LM  is 
halted  while  LMG  is  accessing.  For  the  LM  a  special  procedure  is  needed. 
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Figure  lo  SM  Timing  Diagram 


Built  onto  the  SM  card  Is  a  Peripheral  Interface  Adaptor  (PIA)  chip  with  an 
output  pin  (LMRMW)  used  to  temporarily  disable  the  LMG  from  accessing  SM. 
When  this  LMRMW  Is  high  the  LMG  CS  line  cannot  cause  a  halt  request  to  the 
LM  6800  processor.  Any  LM  software  needing  to  do  a  KMW  operation  must  first 
set  LMRMW  high,  do  the  RMW  operation,  and  set  LMRMW  low.  If  the  LMG  is 
attempting  to  access  SM  at  this  moment.  It  will  simply  appear  as  a  slow  re¬ 
sponse  to  the  handshake. 

Whenever  the  LMG  Issues  a  function  command  (by  writing  into  SM 
location  FF)  or  Issues  a  data  transfer  coonand  (by  writing  Into  SM  location 
FE)  an  Interrupt  to  the  LM  is  generated.  This  Is  implemented  by  decoding 
the  SM  address  bus  with  LMG  CS  and  LMG  WE  and  Inputting  these  to  interrrupt 
control  pins  on  the  PIA. 

Four  access  strobes  are  generated  and  sent  to  the  Front  Panel  (FP) 
card  for  display  on  the  FP. 

Detailed  schematics  can  be  found  In  Appendix  B,  Section  2-B. 

2.2.4  FRONT  PANEL/ICA  CARD 

The  LM  Front  Panel  (FP)  pictured  In  Figure  5  Is  connected  to  a 
FP  driver  card  as  block  diagrammed  In  Figure  11  .  This  FF  card  consists  of 
three  Motorola  Peripheral  Interface  Adaptors  (FIA's)  which  each  have  two 
8  bit  parallel  I/O  ports.  This  Is  a  total  of  six  ports  which  are  memory 
mapped  In  the  LM.  Thus  the  FP  displays  and  switches  are  software  driven  by 
a  subroutine  in  the  LM  which  Is  called  by  the  Update  task.  Ihe  FP  Informa¬ 
tion  Is  only  valid  when  the  LM  Is  running  In  a  real-time  mode  of  operation. 

The  bus  connections  to  the  ICA  are  on  the  same  card  as  the  FP 
FIA's.  These  are  Independent  of  the  FP  and  are  on  the  same  card  only  for 
convenience.  Detailed  schematics  can  be  found  In  Appendix B,  Section  2-C. 
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2.2.S  NIC/TIMER  CARD 

The  Nameplate  Interface  Controller  (NIC)  card,  residing  In  the  LM, 
enables  programs  running  on  the  LM  to  communicate  with  electronic  nameplates 
via  the  subsystem  Information  channel  bus.  This  card  translates  the  LM's 
bus  signals  Into  the  signals  compatible  with  the  SIC  bus.  Also  Installed 
In  the  NIC  card  Is  the  LM's  timer  circuit  which  generates  an  Interrupt  to 
the  LM  processor  every  10  milliseconds.  The  design  of  this  card  Is  described 
In  detail  In  Section  A. 3.1  of  this  document. 

2.3  SOFTWARE  DESIGN 

Software  In  the  Link  Module  (LM)  consists  of  a  real  time  executive  and 
several  tasks  which  Implement  the  LM  functions.  Assembly  language  Is  used 
since  the  FORTRAN  available  for  the  6800  system  does  not  support  the  multi¬ 
tasking  capability  required.  A  top-down,  modular  approach  to  the  software 
design  has  been  used  throughout.  The  LM  software  modules  are  described  In 
the  sections  that  follow. 

2.3.1  LINK  MODULE  SOFTWARE  DECOMPOSITION 

The  Link  Module  (LM)  software  Is  a  multitasking  system,  with  task 
scheduling  controlled  by  a  round  robin  executive.  Each^  task  Is  a  self 
contained  unit  and  performs  a  well  defined  function.  However,  one  task  may 
require  the  services  of  another  task  In  order  to  complete  Its  function. 
Intertask  control  Interaction  Is  achieved  through  calls  to  the  executive. 
Intertask  data  sharing  Is  Implemented  through  global  comnon  variables.  The 
tasks  Include  an  update  timer,  three  handlers,  a  command  Interpreter,  and 
the  non-resident  task.  These  are  diagramned  In  Figure  12  and  listed  In 
Table  2  . 
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Figure  12  Executive  Interactions 


Table  2 

LINK  MODULE  TASKS 


Task  Name  Task 

Number 

Starting  Address 

UPDATE  (Update  time) 

0 

5020 

ICAHND  (ICA  handler) 

1 

7020 

SICHND  (SIC  handler) 

2 

7820 

SMHND  (SM  handler) 

3 

6820 

CMDITR  (Command  Interpreter) 

4 

6020 

NRTSK  (Non-resident  task) 

5 

040D  (usually) 

The  Update  task  works  in  conjunction  with  a  timer  Interrupt  ser¬ 
vice  routine.  The  timer  Interrupt  routine  Increments  a  counter  with  each 
clock  tick.  When  the  Update  task  runs  It  reads  this  tick  counter,  updates 
time  of  day,  and  decrements  each  task^  delay  counters  accordingly.  When  a 
task's  delay  count  reaches  zero,  the  corresponding  task  Is  activated. 

The  Shared  Memory  (SM) ,  Interface  Configuration  Adaptor  (ICA), 
and  Nameplate  (NP)  handlers  perform  comnunlcatlon  and  data  transfers  with 
their  respective  devices.  Each  handler  also  updates  Its  device's  status  In 
Shared  Memory.  The  handlers  run  as  tasks,  and  are  activated  by  other  tasks 
through  executive  requests. 

The  Coionand  Interpreter  task  works  In  conjunction  with  an  LM 
function  Interrupt  routine  which  runs  whenever  the  Link  Manager  (LMG)  sends 
a  conmand  to  the  LM  via  Shared  Memory.  The  Interrupt  routine  checks  the 
command  for  validity  and  flags  the  Command  Interpreter  task  to  execute  the 
command . 

A  non-resident  task  may  be  loaded  and  executed  in  the  LM.  This 
program  may  be  either  uploaded  from  the  Nameplate  or  downloaded  from  the 
LMG.  It  may  be  a  data  I/O,  calibration,  or  subsystem  diagnostic.  However, 
only  one  non-resident  task  may  be  loaded  In  the  LM  at  any  one  time.  This 
task  may  be  started  or  stopped  under  LMG  control. 

Tasks  are  scheduled  for  execution  under  a  round  robin  scheduling 
algorithm.  Details  of  the  executive  and  each  task  are  given  In  the  sections 
that  follow. 

2.3.2  REAL-TIME  EXECUTIVE 

A  real-time  executive  program  Is  used  to  schedule  the  execution 
of  tasks  In  the  Motorola  M6800  microprocessor  based  system.  This  section 
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describes  the  services  available  In  Che  executive  and  defines  how  to  use 
them.  A  description  of  the  functional  aspects  of  the  program  Is  also  given 
here. 

The  executive  Implements  a  round  robin  scheme  for  task  scheduling. 
The  executive  allows  for  up  to  12  tasks  to  be  scheduled.  Including  non¬ 
resident  tasks.  In  this  Implementation  it  permits  only  1  non-resident  task 
and  Includes  only  5  predefined  resident  tasks.  The  5  resident  tasks  are: 
the  update  task,  the  Shared  Memory  (SM)  handler,  the  Subsystem  Information 
Channel  (SIC)  handler,  the  Interface  Configuration  Adaptor  (ICA)  handler, 
and  the  command  Interpreter.  The  non-resident  task  can  be  any  one  of 
several  data  I/O  and  diagnostic  tasks.  This  constraint  can  easily  be  modi¬ 
fied,  if  necessary,  to  Include  more  non-resident  tasks. 

The  Executive  program  allows  each  Installed  task  to  be  in  one  of 
four  possible  states:  dormant,  delayed,  ready,  or  running.  The  task  states 
are  diagrammed  in  Figure  13  .  A  running  task  is  the  one  currently  using 
the  CPU.  A  task  in  the  ready  state  is  waiting  for  Its  turn  to  be  processed. 
A  delayed  task  becomes  ready  when  Its  delay  time  has  elapsed.  A  dormant 
task  will  not  run.  A  delayed  or  dormant  task  may  be  brought  to  the  ready 
state  through  activation. 

Ready  tasks  are  executed  in  a  cyclic  manner,  the  next  ready  task 
in  the  cycle  being  given  control  of  the  CPU.  Once  a  task  has  control  of 
the  CPU,  it  is  up  to  it  to  voluntarily  release  the  CPU.  Therefore,  each 
task  must  not  be  executed  continuously  if  It  requires  excessive  CPU  time, 
otherwise  the  system  may  not  maintain  a  real-time  operation. 

A  running  task  can  call  upon  the  executive  to  modify  the  execu¬ 
tion  status  of  another  task  -  (activate,  abort.  Install  or  remove)  In  which 


25 


Figure  13  Transition  of  States 


case  the  executive  temporarily  regains  control  of  the  CPU,  performs  the 
function,  and  returns  CPU  control  to  the  calling  task.  A  running  task  can 
release  CPU  control  by  calling  upon  the  executive  to  perform  any  of  the 
following  functions  -  relinquish,  exit,  or  delay.  In  which  case  the  execu¬ 
tive  performs  the  function  on  the  calling  task  and  transfers  CPU  control  to 
the  next  ready  task  in  the  cycle.  To  be  able  to  perform  all  the  above  men¬ 
tioned  functions,  the  executive  maintains  tables  containing  the  start 
address,  restart  address,  Initial  stack  pointer,  current  stack  pointer  and 
initial  and  current  state  of  task  for  each  installed  task. 

In  addition  to  task  control  services,  the  executive  also  provides 
services  to  allocate  the  three  device  handlers  to  tasks  In  need  of  them. 

This  ensures  that  not  more  than  one  task  Is  using  a  particular  handler  at 
any  given  time.  The  services  are  called  Shared  Memory  Request  (SMRQ) ,  SIC 
Request  (SICRQ),  and  ICA  Request  (ICARQ) . 

The  executive  also  furnishes  math  functions  which  can  be  used  by 
the  running  task.  The  functions  provided  are  16  bit  divide,  16  bit  multiply, 
binary  to  BCD,  BCD  to  binary,  and  three  special  functions  pertinent  to  the 
processing  required  by  the  subsystems  used  in  this  demonstration.  The 
running  task  can  call  upon  the  executive  to  perform  these  functions.  Upon 
completion,  the  executive  returns  to  the  calling  task  with  the  result. 

Thus  a  total  of  11  executive  services  are  provided.  The  calling 
sequence  and  a  brief  description  of  each  service  Is  described  below. 

2. 3. 2.1  Executive  Services 

There  are  11  executive  services.  Each  service  can  be  requested 
through  the  EXECRQ  macro.  This  macro  simplifies  the  calling  sequence  of 
all  the  services.  The  macro  Is  listed  and  explained  In  Appendix  C,  Section  2-B. 
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The  explanation  of  the  executive  services  Is  given  below. 


1.  Activate:  This  service  Is  used  by  the  running  task  to  bring  any 

other  task  Into  the  ready  state  from  either  the  dormant  or  delayed 
states.  It  has  no  effect  on  a  task  already  In  the  ready  state. 

Calling  sequence:  EXECRQ  ACTVAT,  TASKNO 

where  TASKMO  Is  the  task  //  of  task  to  be  activated 

Register  usage:  A  - 

B  -  //TASKNO 
X  -  unused 

2.  Relinquish:  This  service  transfers  the  running  task  from  the  running 

state  to  the  ready  state.  This  Is  one  of  the  ways  a  task  can  release 
CPU  control,  and  ensures  the  task's  regaining  CPU  control  after  one 
cycle  of  the  round-robin  scheduler,  whereupon  It  can  start  wherever  It 
last  left  off. 

Calling  sequence:  EXECRQ  RELQSH 

Register  usage:  A  -  #1 

B  -  unused 
X  -  unused 

3.  Exit :  This  service  transfers  the  running  task  from  the  running  state 

to  the  dormant  state.  This  also  Is  a  way  for  a  task  to  release  CPU 
control,  but  the  task  runs  again  only  If  activated  by  another  task. 
Execution  of  a  task  that  has  exited  starts  from  the  beginning. 

Calling  sequence:  EXECRQ  EXIT 
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Register  usage: 


A  -  <»  2 


r- 

r; 

i» 

[?■ 


B  -  unused 
X  -  unused 

4.  Delay :  This  service  transfers  a  running  task  to  the  delayed  state. 

This  Is  another  way  for  a  task  to  release  CPU  control.  The  task  will 
automatically  become  ready  only  when  the  delay  time  expires,  unless 
prematurely  activated  by  another  task.  When  the  task  runs  again  It 
will  start  from  wherever  It  last  left  off.  The  delay  time  Is  determined 
by  the  UPDATE  task. 

Calling  sequence:  EXECRQ  DELAY,  TIME 

where  TIME  Is  the  delay  time  In  seconds  If  the  MSB  of  the  8  bits  =  1 
and  Is  the  delay  time  In  lO's  of  milliseconds  if  the  MSB  of  8  bits  =  0. 

Register  usage:  A  -  #3 

B  -  #  TIME 
X  -  unused 

5.  Abort :  The  running  task  can  use  this  service  to  transfer  any  other 

task  from  the  ready  or  delayed  states  to  the  dormant  state.  The  abort¬ 
ed  task  will  run  again  when  activated,  and  execution  will  start  from 
the  beginning. 

Calling  sequence:  EXECRQ  ABORT,  TASKNO 

where  TASKNO  Is  the  task  #  of  the  task  to  be  aborted 

Register  usage:  A  -  #4 

B  -  #TASKNO 
X  -  unused 
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6.  Install I  The  running  task  can  use  this  service  to  Introduce  a 

new  task  Into  the  execution  scheduling  cycle.  At  present  only  one  task 
can  be  Installed  and  will  be  designated  as  task  #5.  Thus  If  there  Is 
already  a  task  designated  as  #5  It  will  have  to  be  'removed'  before 
'Installing'  a  new  one.  The  service  returns  a  status  Indicating  the 
absence  or  presence  of  a  previously  Installed  task. 

To  Install  a  new  task  It  Is  necessary  to  transfer  to 
the  executive  the  starting  address.  Initial  stack  pointer  and  initial 
state  of  the  task. 

Calling  sequence:  set  up  table  as  follows  for  task  to  be  In¬ 

stalled. 


TABADR 


Starting  address 


Initial  stack  pointer 


Initial  state 


Return  status 


ZXECRQ  INSTAL,  TASKNO,  TABADR 


2 

2 

1 

1 


bytes 


where  TASKNO  Is  #  of  the  task  to  be  Installed  (5)  and  TABADR  Is  the 
address  of  the  start  of  the  table  set  up. 


Register  usage: 


A  -  #5 
B  -  #TASKMO 
C  -  ITABADR 


7.  Remove :  This  service  Is  used  by  the  running  task  to  remove  a 

task  from  the  round-robin  cycle.  The  task  will  be  removed  only  If  it 
Is  In  the  delayed  or  dormant  state.  If  It  Is  In  the  ready  state,  the 
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task  will  not  be  removed  and  a  status  will  be  returned  indicating  that 
the  particular  task  was  active. 

Calling  sequence:  EXECRQ  REMOVE,  TASKNO,  STSADR 

where  TASKMO  Is  the  //  of  the  task  to  be  removed  and  STSADR  Is  the  ad¬ 
dress  where  the  status  will  be  returned. 

Register  usage:  A  -  //b 

B  -  #TASKNO 
X  -  //STSADR 

8.  ICA  Request:  The  running  task  can  use  this  service  to  assume  control 

of  the  ICA  handler.  If  the  services  of  the  ICA  handler  have  already 
been  granted  to  another  task  the  service  call  returns  with  a  status 
saying  so.  If  the  handler  is  successfully  allocated  to  the  running 
task,  the  address  of  the  table  of  parameters  to  be  sent  to  the  handler 
is  passed  to  the  handler.  Then,  status  saying  'handler  allocated'  Is 
returned  to  the  calling  task. 

Calling  sequence:  EXECRQ  ICARQ,  ICAFUN,  GROUP,  CHANEL,  OPTION, 

CNSORC,  NUMBYT,  BUFADR,  UFTADR 

where  UFTADR  Is  the  address  where  the  parameter  table  Is  to  be  set  up. 
A  detailed  description  of  other  parameters  will  be  found  In  the  ICA 
handler  section. 

Register  usage;  A  -  f/7 

B  -  unused 
X  -  iVFI  addr. 
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9.  SIC  Request;  The  running  task  can  use  this  service  to  assume  control 
of  the  SIC  handler.  This  service  functions  exactly  like  the  ICA  re¬ 
quest  service. 

Calling  sequence:  EXECRQ  SICRQ,  NPID,  SICFUN,  BUFADR,  BUFSIZ,  UFTADR 

where  UFTADR  is  the  starting  address  of  the  table  of  par2uneters.  For 
a  description  of  other  parameters  please  refer  to  the  SIC  handler 
section. 

Register  usage:  A  -  //8 

B  -  unused 
X  -  )!»UFTADR 

^0*  SM  Request:  The  running  task  can  use  this  service  to  assume  control 

of  the  shared  memory  handler.  This  service  functions  exactly  like  the 
ICA  request  service. 

Calling  sequence:  EXECRQ  SMRQ,  SMFUN,  BUFADR,  BUFSIZ,  UFTADR 

where  UFTADR  Is  the  starting  address  of  the  table  of  parameters.  For 
a  description  of  other  parameters  please  refer  to  the  SM  handler  section. 

Register  usage:  A  -  jS^9 

B  -  unused 
X  -  lUFTADR 

11.  Math:  The  running  task  can  use  this  service  to  perform  any  one 

of  seven  mathematical  functions.  The  task  must  provide  the  arguments 
In  the  calling  sequence.  The  executive  returns  to  the  calling  task 
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with  the  result  of  the  operation  In  the  address  specified  by  the  call¬ 
ing  task. 

General  calling  sequence: 

EXECRQ  MATH,  function,  ADROPl,  ADR0P2,  ADR0P3,  ADR0P4,  RESULT 

where  function  is  any  one  of: 

DMULT  -  Double  multiply  (8  bit  operands,  16  bit  result) 

DDIV  -  Double  divide  (16  bit  operands,  16  bit  result) 

BINBCD  -  Binary  to  BCD  (16  bit  binary  to  5  BCD  digits) 

BCDBIN  -  BCD  to  binary  (  4  BCD  digits  to  16  bit  binary) 

CALCA  -  Calculation  of  synchro  constant  'A'.  Arguments  required 

are  three  synchro  voltages  each  in  8  bit  2's  complement 
form. 

THETA  -  Calculation  of  synchro  angle  '6'.  Arguments  required  are 
three  synchro  voltages  each  in  8  bit  2's  complement  form 
and  value  of  'A* . 

VOUTS  -  Calculation  of  three  synchro  output  voltages  in  8  bit  2's 
complement  form.  Arguments  required  are  '6'  and  'A'. 

ADROPn  is  address  of  operand  n 

and  RESULT  is  address  for  the  result. 

Calling  sequences  according  to  functions: 

EXECRQ  MATH,DMULT,addr.  of  multlpllceuid,addr.  of  multiplier ,,  ,R£SULT 

EXECRQ  MATH, DDIV, addr.  of  dividend, addr.  of  divisor ,, ,RESULT 

EXECRQ  MATH, BCDBIN, addr.  of  BCD, , , ,RESULT 

EXECRQ  MATH, BINBCD, addr.  of  binary ,,, ,RESULT 

EXECRQ  MATH, CALCA, addr.  of  VI, addr.  of  V2,addr.  of  V3,, RESULT 

EXECRQ  MATH, THETA, addr.  of  VI, addr.  of  V2,addr.  of  V3,addr.  of  A, RESULT 

EXECRQ  MATH, VOUTS, addr.  of  6, addr.  of  A,,, RESULT 
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2. 3.2.2  Operation 

To  be  able  to  function  properly,  the  executive  needs  to  keep  track 
of  three  parameters  for  each  task  scheduled  for  execution.  It  must  know  the 
state  (actlve/lnactlve)  of  the  task,  the  address  at  which  the  task  will  re¬ 
sume  execution,  and  the  value  of  the  stack  pointer  when  the  task  resumes 
execution.  All  these  parameters  may  vary  during  the  course  of  execution  of 
a  task,  but  Initially  -  before  the  task  starts  Its  first  execution  -  they 
will  always  have  a  fixed  value  chosen  during  system  generation.  So  the 
Initial  values  of  these  parameters  are  stored  In  ROM  and  during  Its  Initial¬ 
ization  the  executive  copies  these  parameters  Into  RAM.  From  thereon,  the 
executive  examines  and/or  modifies  these  parameters  In  RAM  during  context 
switching. 

The  executive  also  needs  to  know  the  number  of  tasks  Installed. 
This  ntimber  Is  stored  In  a  variable  called  NTASKS,  which  varies  due  to  the 
'Installation*  or  'removal*  of  the  nonresident  task.  The  variable  Is  Ini¬ 
tialized  by  the  executive  during  Its  Initialization.  Since  In  this  appli¬ 
cation  there  are  5  resident  tasks  and  no  Initially  Installed  nonresident 
task,  this  variable  Is  first  set  to  5. 

Thus  we  see  that  during  Its  Initialization  the  execu  :lve  copies 
parameters  from  ROM  Into  RAM  and  sets-up  the  number  of  tasks.  It  also 
allows  the  5  resident  tasks  to  go  through  their  own  Initialization.  All 
this  Is  done  on  power-up. 

Once  this  Is  over,  the  scheduler  part  of  the  executive  takes  over. 
It  determines  which  task  should  get  control  of  the  CPU  by  examining  the 
task  status  of  each  task.  The  first  task  It  comes  across  which  Is  In  the 
active  state  receives  CPU  control.  Before  transferring  control,  the 
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scheduler  gets  the  value  of  the  stack  pointer  and  the  address  where  the  task 
will  begin  execution  (both  from  RAM).  It  then  sets  up  the  stack  pointer  and 
Jumps  to  the  start  address  obtained  from  RAM. 

Whenever  a  task  wants  to  avail  Itself  of  the  executive's  services.  It  will 
make  a  call  to  the  executive  -  through  the  EXECRQ  macro  -  at  which  point  the 
service  dispatcher  part  of  the  executive  will  take  over.  The  service  dis¬ 
patcher  will  examine  the  contents  of  register  A  and  will  jump  to  the  appro¬ 
priate  service.  The  particular  service  will  be  performed  and  then  one  of 
two  things  will  take  place.  If  the  service  is  either  relinquish,  delay  or 
exit,  control  of  the  CPU  will  go  to  the  scheduler  so  that  the  next  active 
task  may  be  scheduled  for  execution.  On  the  other  hand  if  the  call  is  for 
a  service  other  than  the  three  mentioned,  the  executive  will  return  control 
to  the  calling  task. 

The  architecture  of  the  executive  is  portrayed  in  Figure  14.  A 
list  of  routines  used  by  the  executive  and  their  respective  functions,  is 
presented  in  Table  3. 

2. 3. 2. 3  Parameters  and  Variables 

The  executive  requires  certain  parameters  and  maintains  various 
variables  (some  of  which  are  global)  to  enable  its  functioning.  These  vari¬ 
ables  give  a  fair  indication  of  the  state  of  the  executive  and  the  resident 
and  nonresident  tasks,  and  their  examination  is  a  useful  debugging  aid.  A 
brief  explanation  of  the  most  significant  parameters  and  variables  will  now 
be  presented. 

Parameters 

The  task  parametors  that  are  copied  from  ROM  into  RAM  during  the  exe- 
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Figure  14  The  Real-time  Executive  and  Services 


Table  3 


PROGRAMS  AND  THEIR  FUNCTIONS 


PROGRAM  NAME 

DESCRIPTION 

EXEC 

Main  program 

ACTVT 

Service  routine  for  ACTIVATE  function 

ABORT 

Service  routine  for  ABORT  function 

DELAY 

Service  routine  for  DELAY  function  , 

EXIT 

Service  routine  for  EXIT  function 

RELQSH 

Service  routine  for  RELINQUISH  function 

INSTAL 

Service  routine  for  INSTALL  function 

REMOVE 

Service  routine  for  REMOVE  function 

ICARQ 

Service  routine  for  ICA  handler  allocation 

NPRQ 

Service  routine  for  SIC  handler  allocation 

1 

SMRQ 

Service  routine  for  SM  handler  allocation  i 

MATH 

Service  routine  for  MATH  operations  i 

BLDADR 

Adds  the  contents  of  Reg.  A  to  Reg.  X  ; 

CLRACT.CLRACI 

Clears  the  active  bit  of  task  status  word 

GET STS 

Gets  the  status  word  for  a  task  1 

1 

GETADR 

Performs  the  operation:  Reg(X)=2.  Reg(A)+Reg(X) 

GSTADR 

Transfers  task  start  address  to  restart  address 

ADJSTK 

Adjusts  task  stack  pointer  to  Its  Initial  position 

COPY2B 

Copies  two  bytes  of  data  i 

INITIA 

Routine  which  initializes  the  EXEC  and  each  task  ' 

XFER 

Subroutine  that  transfers  a  block  of  N  bytes  from  loc.  1  i 
to  loc.  2  1 

RESTOR 

Copies  start  addr.  +  Initial  SP.  for  nonresident  task  j 

DMULT 

Does  a  double  multiply  ! 

DDIV 

Does  a  double  divide 

BCDBIN 

Converts  A  BCD's  to  2  byte  binary 

BINBCD 

Converts  2  byte  binary  to  5  BCD's 

CALCA 

Calculates  'A'  from  synchro  voltages 

THETA 

Calculates  6  from  synchro  voltages  and  'A' 

VOUTS 

Calculates  synchro  output  voltages  from  6  and  'A' 

SERCH 

Binary  search  routine 

COSINE 

Determines  Cos  6 

cutives  Initialization  are  the  following: 

STAAOR  (Task  starting  address  array)  -  Two  bytes  for  each  resident  task 
giving  the  address  where  the  task  first  starts  execution  after  Initialization. 

STKROM  (Task  stack  pointer  array)  -  Two  bytes  for  each  resident  task 
containing  the  initial  value  of  the  stack  pointer  for  the  task. 

INIZST  (Task  Initial  status  array)  -  One  byte  for  each  resident  task 
specifying  the  Initial  state  of  the  task  at  system  start-up. 

Global  Variables 

The  following  variables  are  used  by  the  executive: 

TSKSTS  (Task  status  array)  -  Initially  copied  from  INIZST,  One  byte 
for  each  task  Indicating  If  the  task  Is  active  ($80)  or  not  ($00).  Also 
accessed  by  the  update  task.  Upon  expiration  of  the  delay  time  of  a  delayed 
task,  the  update  task  changes  the  task's  status  from  Inactive  to  active. 

The  executive  examines  this  array  for  scheduling  of  tasks. 

DLYTIM  (Task  delay  times)  -  One  byte  for  each  task  Indicating  the  de¬ 
lay  time  of  the  corresponding  task.  The  most  significant  bit  shows  the 
delay  time  Is  In  seconds  (1)  or  lO's  of  milliseconds  (0).  The  other  7  bits 
are  a  delay  unit  count.  The  executive  Initializes  the  delay  time  as  re¬ 
quested  by  the  calling  task  and  the  update  task  modifies  It  as  time  ticks. 

MATHVAR  (P,Q,R, TABLE)  -  F,  Q  and  R  are  2  bytes  each  and  TABLE  Is  6 
bytes.  The  math  routines  In  the  executive  utilize  these  variables  during 
computation.  These  are  Initialized  -  with  the  operands  and  address  of  the 
result  -  by  the  macro  whenever  a  task  requests  the  math  service  of  the 
executive. 
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UFTICA  (UFT*  pointer  for  ICA  handler)  -  Two  bytes  containing  the  16  bit 
address  of  the  start  of  the  UFT  table  holding  parameters  to  be  sent  to  the 
ICA  handler.  This  Is  Initialized  by  the  ICA  handler  during  Its  Initializa¬ 
tion. 


UFTSM  (UFT  pointer  for  SM  handler)  -  Two  bytes  containing  the  16  bit 

address  of  the  start  of  the  UFT  cable  holding  the  parameters  to  be  sent  to 

the  SM  handler.  This  Is  initialized  by  the  SM  handler  during  Its  Initial¬ 
ization. 

UFTNP  (UFT  pointer  for  SIC  handler)  -  Two  bytes  containing  the  16  bit 

address  of  Che  start  of  the  UFT  table  holding  the  parameters  to  be  sent  to 

the  SIC  handler.  This  is  Initialized  by  the  SIC  handler  during  the 
Initialization. 

INSFLG  ('Installed'  flag)  -  One  byte  Indicating  whether  a  nonresident 
task  Is  Installed  ($)91)  or  not  (${j(Jjl).  It  is  also  examined  by  the  command 
interpreter. 

A  list  of  global  variables  appears  In  Table  4.  The  Interactions  of 
the  executive  with  other  tasks  Is  portrayed  In  Figure  15. 

Other  Variables 

RSTADR  (Task  restart  address  array)  -  This  Is  Initially  copied  from 
STAADR.  It  has  two  words  for  each  task  containing  the  address  at  which  the 
corresponding  task  next  resu.>«;s  execution. 


User  File  Table 
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LIST  OF  GLOBAL  COMMON  VARIABLES 


STKBAM  (Task  stack  pointer  array)  -  This  Is  Initially  copied  from  STKBOJl. 
It  has  two  words  for  each  task  containing  the  current  value  of  the  stack 
pointer  for  the  task. 

RSTTMP  -  Two  words  for  the  nonresident  task  containing  the  address  at 
which  it  will  first  start  execution.  This  is  analogous  to  STAADR  for  resi¬ 
dent  tasks. 

STKTMP  -  Two  words  for  the  nonresident  task  containing  the  Initial  value 
of  its  stack  pointer.  This  is  analogous  to  STKROM  for  resident  tasks. 

NTASKS  -  One  byte  indicating  the  number  of  tasks  In  the  round-robin. 
Including  nonresident  tasks  If  any.  This  Is  Initialized  to  5  and  changed  to 
6  If  a  nonresident  task  is  Installed. 

There  are  other  variables  used  by  the  executive  but  since  their  descrip¬ 
tion  does  not  in  any  way  shed  light  upon  the  functioning  of  the  executive, 
their  explanation  has  been  omitted. 

2.3.3  UPDATE  TASK 

The  real-time  executive  used  in  this  system  requires  a  task  to 
keep  track  of  time.  The  executive  also  needs  the  facility  of  updating  the 
status  of  delayed  tasks.  The  update  task  ostensibly  fulfills  these  require¬ 
ments,  with  the  help  of  some  hardware  and  an  interrupt  routine. 

The  update  task  maintains  time  in  Julian  day,  hours,  minutes,  and 
seconds.  It  decrements  the  delay  times  in  the  delay-time  array  of  the 
executive.  It  also  maintains  6  independent  timers  for  the  handlers. 
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2. 3. 3.1  Operation 

In  order  for  It  to  count  time,  the  update  task  must  have  access 
to  a  hardware  clock.  Each  clock  pulse  causes  an  Interrupt  which  Is  serviced 
by  an  Interrupt  routine  called  CLOCK.  The  Interrupt  routine  accumulates  the 
number  of  pulses  received  from  a  100  Hz  clock. 

The  update  task  Is  scheduled  for  execution  In  the  same  way  as 
other  tasks.  Each  time  the  update  task  runs.  It  checks  to  see  If  any  pulses 
have  been  accumulated  by  the  Interrupt  routine.  It  decrements  the  delay 
times  of  all  delayed  tasks  by  the  amount  of  time  the  number  of  pulses  add 
up  to.  It  checks  the  resulting  delay  time,  and  If  the  time  has  expired  It 
changes  the  state  of  the  corresponding  task  from  'delayed'  to  'ready'. 

Figure  16  shows  the  structure  of  the  update  task. 

Next,  the  update  task  decrements  the  6  Independent  timers  used 
by  the  handlers.  These  timers  are  In  units  of  10  milliseconds  and  thus 
allow  a  maximum  time  count  of  2.55  seconds. 

Lastly,  the  update  task  renews  the  system  time.  The  time  -  In 
days,  hours,  minutes,  and  seconds  -  Is  maintained  In  BCD  data  format. 

The  task  then  relinquishes  control  of  the  CPU  and  awaits  for  Its 
turn  In  the  next  scheduling  cycle.  In  the  next  cycle  It  goes  through  the 
above  mentioned  steps  In  the  same  fashion. 

Since  the  update  task  runs  during  every  scheduling  cycle.  It  Is 
used  to  call  upon  a  subroutine  which  refreshes  the  front-panel  of  the 
system. 

A  detailed  description  of  the  update  task  Is  presented  In  Appendix 
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2. 3. 3. 2  Interactions  with  other  Tasks 

The  update  task  has  Interatlons  with  the  executive,  the  handlers, 
the  Interrupt  service  routine,  the  comnand  Interpreter,  and  the  nonresident 
tasks.  These  Interactions  are  shown  In  Figure  17  along  with  the  names  of 
the  variables  through  which  they  take  place.  For  a  detailed  description  of 
these  variables,  refer  to  Appendix  C,  Section  2-C. 

2.3.4  ICA  HANDLER 

The  ICA  handler  is  one  of  the  resident  tasks  in  the  link  module 
and  Is  designated  as  task  //I.  It  Is  a  software  program  which  provides  an 
Interface  between  a  task  wanting  to  use  tbc-  ICA  and  the  ICA  Itself.  It 
translates  general  commands  from  a  task.  Into  specific  commands  recognizable 
by  the  ICA.  It  also  provides  a  means  of  transfer  of  data  and  status  between 
a  task  and  the  ICA,  taking  care  of  all  the  details  Invols'ed  with  this  trans¬ 
fer.  For  a  task,  this  Implies  a  simplified  means  of  interacting  with  the 
ICA. 

The  handler  communicates  with  the  ICA  through  the  ICA  buffers.  A 
map  of  these  buffers  Is  given  In  Figure  18.  As  shown  in  this  figure,  some 
of  these  buffers  are  used  to  configure  the  ICA,  and  others  are  used  for 
transferring  data. 

2. 3. 4.1  Handler  Functions 

The  ICA  handler  has  3  basic  functions: 

1.  Configure 

2.  Control 


3. 


Data  transfer 


Figure  17  Update  Task  Interactions 
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Figure  18  Memory  Map  of  ICA  Buffers 


A  brief  description  of  each  of  these  is  given  below. 


Configure;  This  function  has  two  options  -  read  and  write.  If  the 
option  is  'Read',  the  handler  transfers  the  existing  configuration  to  a 
specified  buffer  address.  If  the  option  is  'Write',  the  handler  transfers 
the  desired  configuration  from  a  specified  address  to  the  ICA  buffers. 

The  ICA  has  several  configurations,  each  of  which  defines  a  particular 
combination  of  states  of  its  hardware.  Any  configuration  consists  of  7 
bytes  of  data.  The  handler  uses  this  data  to  configure  the  ICA.  A  list  of 
configurations  is  given  in  Table  5. 

Control:  This  function  has  3  options  -  online,  offline  and  reset. 

'Online'  enables  outputs  from  the  ICA,  'Offline'  disabled  outputs  from  the 
ICA.  'Reset'  disables  both  Inputs  and  outputs. 

Data  Transfer;  This  function  has  2  options  -  input  and  output.  The 
data  must  be  transferred  to  or  from  the  handler,  in  a  buffer.  The  handler 
assumes  that  the  data  being  transferred  is  compatible  with  the  configuration 
of  the  ICA.  However,  if  the  option  is  input  and  the  ICA  is  configured  for 
output  or  vice-versa,  the  handler  detects  the  error. 

2. 3. 4. 2  Calling  Sequences 

The  services  of  the  handler  must  be  requested  through  the  execu¬ 
tive.  The  request  to  the  executive  is  made  through  the  following  macro  call: 

EXECRQ  ICARQ,  ICAFUN,  GROUP,  CHANEL,  OPTION,  CNSORC,  NUMBYT,  BUFADR,  UFTADR 

EXECRQ  is  a  macro  defined  to  form  a  table  of  all  these  parameters.  The  table 
will  start  at  the  UFT  address  specified  and  will  be  set  up  as  shown  in  Fig¬ 
ure  • 
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Table  5 

ICA  CONFIGURATIONS 


TYPE 

WORD  1 

LEVEL 

LO 

LEVEL 

THRSH 

COUN 

AINAC  S.E. 

C3 

36 

80 

60 

02 

AINAC  DIFF. 

C7 

3j7 

40 

80 

60 

02 

AINDC  S.E. 

83 

3fg 

40 

60 

02 

AINDC  DIFF. 

87 

3Qf 

40 

80 

60 

02 

AOUTAC  S.E. 

CB 

52 

kfi 

00 

60 

02 

AOUTAC  DIFF. 

DF 

52 

40 

80 

60 

02 

AOUTDC  S.E. 

8B 

52 

40 

80 

60 

02 

AOUTDC  DIFF. 

9F 

52 

40 

80 

60 

02 

SYNIN 

CB 

10 

40 

00 

60 

02 

SYNOUT 

CB 

20 

40 

80 

60 

02 

SINREF 

0B 

42 

40 

80 

60 

02 

SINFLG 

0B 

46 

80 

60 

02 

SOUT 

0B 

82 

40 

80 

60^ 

01 

DINREF  S.E. 

03 

30 

40 

80 

60 

02 

DINREF  DIFF. 

07 

30 

40 

80 

60 

02 

DINMOM  FOL. 

23 

32 

4J0' 

80 

60 

02 

DINMOM  LAT. 

23 

33 

40 

80 

60 

02 

DOUT 

0B 

52 

40 

80 

6*. 

02 

UFTADR 
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Figure  19  Parameter  Table  Set-up  by  Macro 


If  the  executive  grants  the  request  for  the  handler,  then  It  saves 
the  pointer  to  this  table  -  the  UFT  address.  When  the  ICA  handler  runs  the 
next  time.  It  retrieves  the  UFT  address  and  parameters,  and  performs  the 
function  as  specified  by  the  parameters. 

An  explanation  of  the  parameters  In  the  calling  sequence  Is  given 

below. 


ICAFUN  -  This  parameter  specifies  the  function.  It  could  be 
CONFIG,  CONTRL,  or  DATATR. 

GROUP  -  This  Is  used  only  when  ICAFUN  is  DATATR,  and  when  the 

data  being  transferred  Is  analog.  It  specifies  the  chan¬ 
nel  and  could  be  1,  2,  3,  4,  or  5  (for  all  channels). 

OPTION  -  Every  function  has  certain  options.  When  ICAFUN  is 

CONFIG,  possible  options  are  READ  and  WRITE  and  are  used, 
respectively,  to  read  or  write  the  configuration.  When 
ICAFUN  Is  CONTRL  the  possible  options  are  RESET,  ONLINE, 
and  OFFLINE.  RESET  resets  the  ICA,  ONLINE  enables  out¬ 
puts,  and  OFFLINE  disables  them. 

When  ICAFUN  is  DATATR  the  possible  options  are  INPUT 
and  OUTPUT  and  are  used,  respectively,  to  Input  and  out¬ 
put  data. 

CNSORC  -  This  parameter  defines  the  source  of  the  configuration. 

If  the  configuration  Is  from  the  LMG  this  parameter  Is 
'0'  and  If  the  configuration  Is  from  the  nameplate  this 
parameter  Is  '1*. 
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NUMBYT  -  This  parameter  holds  the  number  of  bytes  either  to  be 
transferred  or  that  have  been  transferred.  It  Is  not 
necessary  to  supply  the  number  of  bytes  to  be  transferred 
since  In  all  cases  this  Is  knovm  aprlorl.  However,  this 
parameter  does  hold  the  number  of  bytes  successfully 
transferred,  after  the  transfer  takes  place.  If  this 
parameter  Is  zero  It  Indicates  that  the  transfer  was 
unsuccessful. 

BUFADR  -  This  parameter  holds  the  address  of  the  7  bytes  of  con¬ 
figuration  that  will  be  used  If  ICAFUN  Is  CONFIG  and  the 
option  Is  WRITE.  For  the  same  function  If  the  option  Is 
READ,  this  parameter  holds  the  address  of  the  buffer  Into 
which  the  configuration  will  be  read. 

If  ICAFUN  is  DATATR  then  BUFADR  holds  the  address 
of  the  buffer  to  or  from  where  the  data  will  be  trans¬ 
ferred,  depending  on  the  OPTION. 

If  ICAFUN  Is  CONTRL,  this  parameter  Is  not  used. 

In  the  table  of  parameters  as  shown  In  Figure  19,  the  first 
entry  Is  'Return  status'.  This  holds  the  status  of  the  operation  as  return¬ 
ed  by  the  handler.  The  various  status  codes  and  their  meaning  Is  given  In 
Table  6. 


2. 3. 4. 3  ICA  Handler  Design 

The  ICA  handler  has  an  Initialization  section  which  Is  Invoked  by 
the  executive  during  the  executive's  Initialization.  During  Initialization 
the  handler  sets-up  the  Peripheral  Interface  Adapters  (PIA)  and  the  syn- 
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Table  6 


ICA  HANDLER  STATUS  CODES 
Status  Description 

0  Success 

1  Handler  allocated. 

2  Handler  not  allocated. 

4  Function  in  progress. 

-1  Invalid  function. 

-2  Group  not  configured. 

-3  Parity  error  during  serial  input. 

-4  Invalid  configuration. 

-5  No  data  received  during  serial  input. 

-6  Parity  error  during  serial  output. 

-7  Data  not  transmit  during  serial  output. 

-8  Invalid  I/O  request:  group  set  for  synchro  output. 

-9  Invalid  I/O  request:  group  set  for  synchro  input. 

-10  Invalid  I/O  request:  group  set  for  analog  output. 

-11  Invalid  I/O  request:  group  set  for  analog  input. 

-12  Invalid  I/O  request:  group  set  for  discrete  output. 

-13  Invalid  I/O  request:  group  set  for  discrete  input. 

-14  Invalid  I/O  request:  group  set  for  serial  output. 

Invalid  I/O  request:  group  set  for  serial  input. 
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chronous  serial  data  adapters  (SSDA)  which  form  part  of  the  ICA  buffers. 

The  handler  Initializes  all  Its  variables  and  sets  the  ICA  In  the  reset 
state.  It  also  Initializes  the  UFT  pointer,  UFTICA,  to  a  parameter  table 
which  will  require  the  handler  to  perform  the  update  function.  The  update 
function,  though  not  a  'full-fledged'  function  of  the  handler,  updates  the 
ICA  status  in  shared  memory. 

Once  the  Initialization  is  over,  the  handler  runs  periodically 
every  one  second.  Whenever  another  task  requests  the  handler's  services 
this  period  is  disrupted  since  the  handler  immediately  attends  to  the  re¬ 
quest.  Each  time  the  handler  runs,  it  first  gets  the  parameter  table 
pointer  from  UFTICA.  From  the  parameter  table  it  gets  the  function  and 
performs  the  required  steps  corresponding  to  that  function. 

After  performing  any  function,  the  handler  sets  UFTICA  to  point 
to  the  parameter  table  holding  the  update  function.  Thus,  until  the  handler 
is  requested  by  another  task  it  periodically  performs  the  update  function. 
This  structure  of  the  handler  is  depicted  in  Figure  20. 

The  three  major  functions  of  the  handler  are  implemented  as  sub¬ 
routines.  Each  of  these  subroutines,  in  turn,  call  upon  a  host  of  other 
subroutines  at  the  secondary  level.  The  subroutines  in  the  handler  and 
their  hierarchy  are  shown  in  Figure  21.  For  a  detailed  description  of 
these  subroutines  please  refer  to  Appendix  C,  Section  2-D. 

The  handler  has  interactions  with  the  executive  through  UFTICA, 
with  the  update  task  through  the  independent  timers  TIMERS  and  TIMER6,  and 
with  shared  memory  through  ICASTS.  These  interactions  are  shown  in  Figures 
15  ,  17,  and  the  shared  memory  map  in  Figure  28,  respectively.  For 

further  details  about  these  global  variables  please  refer  to  Appendix  c. 


Section  2-D. 
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2.3.5 


SIC  HANDLER 


The  SIC  handler  provides  tasks  running  In  the  link  module  with  a 
simple  to  use  Interface  to  the  subsystem  Information  channel  (SIC) .  The 
handler  allows  a  calling  task  to  make  a  single  call  to  request  a  relatively 
complex  function  be  performed.  The  SIC  handler  will  translate  a  request 
Into  several  commands  which  are  sent  to  an  electronic  nameplate  to  perform 
the  function  requested.  All  the  detailed  timing  and  control  required  for 
communication  with  electronic  nameplates  are  performed  by  the  handler. 

2. 3. 5.1  SIC  Handler  Functions 

This  section  describes  the  functions  of  the  SIC  handler.  Table 
7  lists  all  SIC  handler  functions  Implemented. 

2. 3. 5. 1.1  SIC  Status  In  Shared  Memory 

The  SIC  handler  periodically  updates  a  status  byte  In  shared 
memory.  This  byte  reflects  the  status  of  the  subsystem  Information  channel 
as  shown  In  Figure  22.  The  handler  updates  this  byte  every  0.5  seconds. 

2. 3. 5. 1.2  SIC  Initialization 

Any  time  a  nameplate  Is  added  to  or  removed  from  the  SIC,  a  re¬ 
quest  for  Initialization  must  be  made  to  the  handler.  This  Is  accomplished 
through  the  SIC  handler  function  SICINT.  This  function  request  causes  the 
handler  to  reset  the  nameplate,  to  run  the  nameplate's  diagnostic  program, 
and  to  build  the  SIC  status  table  shown  In  Figure  23.  This  Initialization 
procedure  Is  the  only  way  bits  7  and  6  (SIC  hardware  failure  and  SIC  con¬ 
figuration  changed)  of  the  SIC  status  byte  In  shared  memory  may  be  reset 
after  a  SIC  status  condition  has  caused  them  to  be  set. 
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SIC  hardware  failure  (master  NP  or  NIC),  used 
as  No-Go/Go  bit. 

SIC  configuration  changed  since  initialization 
(SIC  needs  to  be  reinitialized). 

At  least  one  NP  is  present. 

SIC  has  been  initialized. 

SIC  maintenance  record  area  on  the  master  NP 
is  full. 

SIC  in  reset  state. 


Figure  22  SIC  Status  Byte  in  Shared  Memory 


*See  Section  4  for  format  of  these 
diagnostic  result  bytes. 


Figure  23  SIC  Status  Table 
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2. 3.5. 1.3  Load  Functions 

The  load  functions  (LDDIR.LDCFN.LDCNV,  and  DMPWRT)  cause  different 
areas  of  a  nameplate's  memory  to  be  read  and  stored  In  the  area  specified 
by  the  calling  task.  The  type  of  data  each  function  causes  to  be  loaded  Is 
Indicated  In  Table  7. 

2. 3. 5. 1.4  Maintenance  Record  Functions 

A  task  running  In  the  LM  may  write  maintenance  records  regarding 
the  subsystem's  performance  Into  the  read/write  area  of  a  nameplate's  mem¬ 
ory.  The  SIC  handler  function  WRTREC  Is  used  to  perform  this  function.  A 
maximum  of  14  bytes  (one  record)  may  be  written  at  a  time.  The  format  of  a 
maintenance  record  Is  described  In  Section  4.1.3.  Records  are  written 
sequentially  In  the  nameplate's  read/write  memory. 

The  RDREC  command  Is  used  to  read  a  previously  written  record.  A 
record  pointer  Is  used  to  specify  the  first  record  to  be  read.  The  function 
RDREC  causes  the  specified  number  of  records  to  be  read  starting  with  the 
record  pointed  to  by  the  record  pointer.  The  function  RECPOS  Is  used  to 
move  the  record  pointer  to  a  desired  record.  There  are  four  sub-functions 
(POSFUN)  of  the  function  RECPOS  used  for  this  pointer  as  Indicated  In  Table 
7. 

The  records  may  also  be  read  by  the  load  function,  DMPWRT,  which 
reads  all  16  records  (256  bytes  total)  from  the  nameplate  at  one  time. 

The  function  ERAWRT  simulates  the  erasure  of  the  nameplate's  read/write 
memory.  The  record  pointer  Is  set  to  point  to  the  first  record  as  a  result 
of  this  erase  function. 
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Table  7 


SIC  HANDLER  FUNCTIONS 


FUNCTION 

CODE 

(SICFUN) 

DESCRIPTION 

UPDTSM 

JS 

Update  SIC  status  in  shared  memory. 

SICINT 

1 

Initialize  SIC. 

LDDIR 

2 

Load  nameplate's  directory. 

LDCFN 

3 

Load  ICA  configuration  table  from  the 
nameplate. 

LDCNV 

4 

Load  the  subsystem's  data  I/O  conver¬ 
sion  program  from  the  nameplate. 

5 

Reserved . 

6 

Reserved . 

WRTREC 

7 

Write  a  record  into  the  nameplate. 

DMPWRT 

8 

Load  all  of  the  nameplate's  read/writt 
memory  (record  area). 

ERAWRT 

9 

Simulate  erasure  of  the  nameplate's 
read/write  memory. 

RECPOS 

U0 

Positions  the  record  pointer  to  a 
particular  record.  The  type  of  posi¬ 
tioning  (POSFUN)  which  may  be  re¬ 
quested  are: 

•  EDD:  (POSFUN^l)  end  of  data; 

positions  record  pointer  to 
the  first  record  following 
the  end  of  written  records 
(l.e.  the  first  empty  record) 
Note:  this  is  where  the 
record  pointer  is  set  after 
a  record  has  just  been 
written.  The  record  pointer 
value  is  ignored  in  writing 
records.  Records  are  always 
written  sequentially. 

Table  7  (Continued) 
SIC  HANDLER  FUNCTIONS 


FUNCTION 


RDREC 


CODE  DESCRIPTION 

(SICFUN) 

•  BOD:  (POSFUNb2)  beginning  of  data; 

positions  the  record  pointer 
to  the  first  record  In  the 
read/write  memory. 

•  BACKREC:  (POSFUN-3)  backup  the  re¬ 

cord  pointer  the  specified 
number  of  records. 

•  FUDREL:  (POSFUN>4)  advance  the  re¬ 

cord  pointer  the  specified 
number  of  records. 

11  Read  the  specified  number  of  records 
(NUMREC)  from  the  nameplate  starting 
at  the  record  denoted  by  the  record 
pointer. 
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2. 3.5. 2  SIC  Handler  Calling  Sequence 


A  call  to  this  handler  by  a  task  requesting  a  function  is  made  by 
a  request  to  the  executive.  The  executive  builds  a  user  file  table  (UFT), 
consisting  of  the  parameters  specified  by  the  calling  task,  and  passes  It 
to  the  SIC  handler.  Then  the  executive  sets  the  SIC  handler  to  a  ready 
state,  eliminating  any  remaining  delay  the  handler  had,  so  that  the  handler 
will  run  when  its  turn  in  the  round  robin  schedule  is  reached.  Note,  how¬ 
ever,  that  control  is  returned  immediately  to  the  calling  task  after  the 
SIC  handler  is  set  ready.  Thus  the  calling  task  must  relinquish  control  to 
allow  the  handler  to  run. 

The  format  of  a  request  to  the  executive  for  this  SIC  handler  is: 


EXECRQ  SICRQ,  NPID,  SICFUN,  BUFADR,  BUFSIZ,  UFTADR 


where 


EXECRQ:  indicates  a  request  of  the  executive  is  required 

SICRQ  :  indicates  the  SIC  handler  is  requested 

NPID  :  specifies  which  nameplate  is  desired  to  perform  function 

(must  always  equal  zero  in  this  Implementation) 

SICFUN:  specifies  what  function  is  requested  of  the  SIC  handler 

BUFADR:  specifies  the  starting  memory  address  of  the  memory  area 

(or  POSFUN)  in  the  link  module  that  data  is  to  be  loaded  into  (load 
functions)  or  copied  out  of  (write  record  function).  On 
a  record  positioning  function  this  parameter  becomes  the 
type  of  record  pooltloning  required  (POSFUN). 

BUFSIZ:  specifics  the  maximum  size  of  the  memory  area  denoted  by 

(or  NUMREC)  #BUFAOR.  On  a  record  positioning  function  this  parameter 
becomes  the  number  of  records  to  be  processed.  On  the 
completion  of  any  function  this  parameter  is  changed  to 
represent  the  number  of  bytes  actually  transferred. 

UFTADR:  specifies  the  memory  area  where  the  UFT  is  to  be  stored. 

The  area  size  snist  be  at  least  8  bytes. 
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Figure  24  shows  the  UFI  built  as  a  result  of  this  request. 

Any  time  after  a  request  Is  made  to  this  handler,  the  calling  task 
may  examine  the  first  word  of  the  UFT  to  obtain  the  present  status  of  the 
request.  The  request  status  codes  are  given  In  Table  8. 

2.3.5. 3  SIC  Handler  Design 

Figure  25  shows  the  flowchart  for  the  main  routine  of  the  SIC 
handler  task  SICHND.  The  SIC  hardware  and  SIC  Internal  variables  are  Ini¬ 
tialized  through  a  subroutine,  HNDINT,  called  by  the  executive  as  part  of 
the  link  module  power-up  Initializations.  After  this  the  SIC  handler  only 
executes  the  loop  portion  of  the  program  shown  In  Figure  25. 

When  another  task  running  In  the  LM  requests  of  the  executive  an 
SIC  handler  function,  the  executive  sets  up  an  SIC  handler  user  file  table 
(UFT)  for  that  request.  The  executive  modifies  the  global  variable  SICUFT 
to  point  to  this  UFT.  The  executive  clears  any  delay  the  SIC  handler  may 
have  and  sets  the  task  status  to  ready  so  that  It  will  run  when  Its  turn  In 
the  round  robin  schedule  comes  up. 

When  the  SIC  handler  starts  execution  It  calls  the  subroutine 
FUNEXE  to  obtain  and  decode  the  function  requested  out  of  the  UFT  and  then 
call  the  proper  function  subroutine  to  execute  the  requested  function.  Each 
function  has  Its  own  function  subroutine.  These  subroutines  call  lower 
level  subroutines,  each  of  which  perform  a  special  service  needed  In  pro¬ 
cessing  the  requested  function.  Table  9  gives  an  hierarchical  presentation 
of  the  subroutines  used  In  the  SIC  handler.  Once  the  function  request  has 
been  processed  the  status  In  the  UFT  (first  byte  of  UFT)  Is  changed  to  In¬ 
form  the  calling  task  the  status  of  Its  request.  The  subroutine  FUNEXE 
then  returns  control  to  the  main  routine  of  this  handler. 


Table  8 


SIC  HANDLER  REQUEST  STATUS  CODES 


STATUS 

CODE 

DESCRIPTION 

RQREJ 

+2 

Request  rejected  by  executive  because 
this  handler  is  being  used  by  another 
task. 

BUSY 

+1 

The  handler  is  in  the  process  of  exe¬ 
cuting  the  requested  function. 

SUCC 

0 

Requested  function  completed  success¬ 
fully  . 

INVFUN 

-1 

Invalid  function  requested. 

COMERR 

-2 

SIC  communication  with  nameplate  In 
error. 

FUNERR 

-4 

Nameplate  error  in  execution  of  func¬ 
tion. 

INTERR 

-5 

SIC  not  properly  initialized. 

INVID 

-10 

Invalid  nameplate  ID  specified. 

OVERFL 

-11 

The  size  of  the  data  requested  to  be 
loaded  Is  larger  than  the  buffer  area 
specified  to  receive  it. 

EDWM 

-12 

This  status  Is  set  when  trying  to 
read,  write  or  move  the  record  point¬ 
er  beyond  the  end  of  the  nameplate's 
read/write  memory. 

BOUM 

-13 

This  status  Is  set  when  trying  to 
move  the  record  pointer  before  the 
start  of  the  nameplate's  read/write 
memory. 

SICHND 


FUNEXE 


SICUFT 


UPDTSM 


SICUFT  s 
LOCAL  UFT 


delay 

500  nf\s<.c 


Comments 


Jiecoete.  QxtcJuJbL 
functioK 


Uf>dedtc  SIC.  staJTus 

IK.  skarwl  mewerij 

Loco-t  DF7  ^r\ctidi\=! 

skftireol  Tr\trr\or\j 

Rtt^ue&y  extcidxvt 
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Figure  25  SIC  Handler  Task 
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SICRX  is  really  a  "receiver  data  available"  Interrupt  handler. 


The  subroutine  UPDTSM  is  then  called  to  check  and  update  the  SIC 
status  byte  in  shared  memory.  Then  the  UFT  pointer,  SICUFT,  is  modified  to 
point  to  a  local  UFT  containing  the  function  "update  status  in  shared  mem¬ 
ory".  The  SIC  handler  then  delays  500  milliseconds.  If  no  task  has  re¬ 
quested  an  SIC  handler  function  by  the  time  this  delay  expires,  the  execu¬ 
tive  will  activate  this  handler.  The  SIC  handler  will  then  proceed  to 
execute  the  function  in  this  local  UFT.  The  subroutine  FUNEXE  merely  returns 
control  if  it  decodes  the  function  "update  status  in  shared  memory".  Then 
UPDTSM  is  called  to  perform  this  function.  This  scheme  provides  for  a 
periodic  update  of  the  status  in  shared  memory  even  if  a  handler  function 
is  not  requested  by  a  task. 

Detailed  information  on  all  of  the  subroutines  comprising  the  SIC 
handler  is  given  in  Appendix  C,  Section  2-A. 

2.3.6  SHARED  MEMORY  HANDLER 

The  Shared  Memory  Handler  (SMHND)  runs  as  a  task  in  the  LM  under 
control  of  the  real-time  executive.  The  three  major  functions  of  this 
handler  are:  (1)  arbitrate  SM  buffer  control  for  data  transfers,  (2)  clear 
and  set  various  flags,  and  (3)  update  the  LM  status  byte  in  the  SM.  The 
handler  runs  at  least  every  0.5  seconds,  since  at  the  end  of  every  run  it 
issues  an  executive  DELAY  request  of  0.5  seconds.  This  Insures  that  even 
if  no  task  activates  the  shared  memory  handler,  it  is  periodically  activated 
by  the  executive  to  update  the  LM  status  byte  in  SM.  This  LM  status  byte 
is  not  updated  with  every  SMHND  call  but  only  after  a  minimum  of  0.5  seconds. 

The  shared  memory  handler  is  activated  through  an  executive  re¬ 
quest  by  another  task.  The  reason  for  this  is  to  relieve  the  calling  task 
of  the  responsibility  of  needing  to  know  any  SM  addresses  or  handshake 
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protocols.  This  is  particularly  Important  for  nonresident  tasks  which  have 
no  knowledge  of  any  LM  addresses  or  handshakes. 

2. 3. 6.1  SM  Handler  Functions 

Following  Is  a  description  of  each  of  the  ten  SMHND  functions 
listed  In  Table  10.  The  various  status  returns  from  these  functions  are 
listed  In  Table  11. 

UPDSTS  (Update  status)  is  function  number  This  function  Is 
used  to  update  the  LM  status  byte  In  SM. 

SETSTS  (Set  status)  is  function  number  1.  This  function  is  used 
to  write  the  calling  task  status  byte  Into  the  LA  status  byte  In  SM. 

SETFLG  (Set  flag)  is  function  number  2.  This  function  is  used  to 
set  the  flag  bit  in  DXSTS  byte  in  SM  to  indicate  a  calling  task  error  con¬ 
dition. 

CLRFLG  (Clear  flag)  is  function  number  3.  This  function  is  used 
to  clear  the  flag  bit  in  DXSTS  byte  in  SM. 

SIREAD  (Read  SI  (DXSTS))  is  function  number  4.  This  function  is 
used  by  the  calling  task  to  read  the  DXSTS  byte  in  SM. 

SEQGET  (Sequential  get)  is  function  number  5.  This  function  is 
used  to  get  sequential  data  from  SM  data  buffer  which  has  been  loaded  by 
the  LMG. 

REFGET  (Refreshed  get)  is  function  number  6.  This  function  is 
used  to  get  refreshed  data  from  SM  data  buffer  which  has  been  loaded  by  the 
LMG. 

SEQPUT  (Sequential  put)  is  function  number  7.  This  function  is 
used  to  put  sequential  data  into  SM  data  buffer  for  the  LMG  to  read. 

REFPUT  (Refreshed  put)  is  function  number  8.  This  function  is 
used  to  put  refreshed  data  into  SM  data  buffer  for  the  LMG  to  read. 
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Table  10 
SMHND  FUNCTIONS 


0 

UPDSTS 

- 

Update  LM  status. 

1 

SETSTS 

- 

Set  task  status. 

2 

SETFLG 

- 

Set  flag  bit. 

3 

CLRFLG 

- 

Clear  flag  bit. 

4 

SIREAD 

- 

SI  byte  read. 

5 

SEQGET 

- 

Sequential  data  get. 

6 

REFGET 

- 

Refreshed  data  get. 

7 

SEQPUT 

- 

Sequential  data  put. 

8 

REFPUT 

- 

Refreshed  data  put. 

9 

FLGINZ 

- 

Flags  initialization. 

Table  11 


SMHND  STATUS  RETURN  CODES 

+1  Data  not  ready,  or  pending. 
0  Success. 

-1  Invalid  function  number. 

-2  BUFSIZ  <0  or  >63. 

-3  BUFSIZ  too  small  (eg  <  WSC) . 
-10  SEQPUT:  RDY  or  REQ  /  0 


FLGINZ  (Flags  Initialization)  is  function  number  9.  This  function 
is  used  to  initialize  all  the  data  transfer  handshake  flags. 

2. 3.6.2  SM  Handler  Calling  Sequence 

The  shared  memory  handler  is  called  by  another  task  through  an 
executive  request.  The  executive  builds  a  UFT  table  as  shovm  in  Figure  27 
consisting  of  the  parameters  specified  by  the  calling  task,  and  passes  it 
to  the  SMHND.  The  executive  sets  the  SMHND  task  to  the  ready  state  and  re¬ 
turns  control  immediately  to  the  calling  task.  Thus  the  calling  task  must 
relinquish  CPU  control  to  give  the  SMHND  a  chance  to  run.  The  calling 
sequence  is  as  follows: 

label  EXECRQ  SMRQ,SMFUN,BUFADR,BUFSIZ,UFTADR  where; 

EXECRQ  -  invokes  the  executive  request  macro. 

SMRQ  -  identifies  EXECRQ  as  being  for  SMHND. 

SMFUN  -  identifies  which  of  the  ten  functions. 

BUFADR  -  starting  address  of  the  user  buffer. 

BUFSIZ  -  #  of  bytes  available  in  user  buffer. 

UFTADR  -  user  file  table  containing  above  information  to  be  pass¬ 
ed  to  handler.  See  Figure  27. 

Table  11  lists  the  request  status  return  codes.  The  calling 
task  may  obtain  the  present  status  of  the  request  by  examining  the  first 
byte  of  the  UFT  and  relinquish  CPU  control  if  the  request  has  not  completed. 

2. 3.6. 3  SM  Handler  Design 

The  general  handler  architecture  is  shown  in  Figure  26.  Upon 
being  called  it  first  checks  the  validity  of  the  calling  parameters.  If 
valid  then  a  call  is  made  to  the  particular  function  subroutine  which  exe- 
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Figure  26  SMHND  Rowchort 
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Figur*  27  SMHND  Calling  Poromatars  Toblt 


cutes  the  requested  function.  Then  a  check  is  made  to  see  If  the  handler's 
local  time  of  0.5  sec  has  expired.  If  so,  then  the  LM  status  byte  In  SM  Is 
updated  and  the  timer  Is  reset  to  0.5  sec.  Next  the  UFT  pointer  Is  set  to 
point  to  the  local  UFT  table  containing  the  function  request  UPDSTS  (M)  and 
an  EXEC  DELAY  of  0.5  sec  Is  requested.  This  Insures  that  LM  status  Is  up¬ 
dated  periodically  between  0.5  and  1  sec.  Refer  to  Appendix  c.  Section  3-F  fo. 
detail  on  the  structure  and  workings  for  each  function. 

2. 3. 6. 4  SM  Communication  Protocol 

Figure  28  shows  the  organization  and  usage  of  the  Shared  Memory. 
There  are  256  bytes  divided  Into  four  64  byte  areas.  ;0-63  Is  labeled  IOBUFJ0 
and  is  for  data  output  from  LMG  to  subsystem.  64-127  Is  labeled  lOBUFl  and 
is  for  data  input  to  LMG  from  subsystem.  128-191  Is  labeled  LMBUF  and  Is 
used  for  LM  Function  Command  parameters  between  the  LM  and  the  LMG.  192-255 
Is  used  for  all  the  control  and  status  information  between  the  LM  and  the  LMG. 

2. 3. 6. 4.1  Function  Command  Protocol 

The  LMG-LM  function  command  handshakes  are  handled  by  an  Interrupt 
routine  rather  than  the  Shared  Memory  Handler.  Two  bytes  In  Shared  Memory 
are  used  for  the  function  command  handshakes:  1)  Address  FF  hex  Is  written 
by  the  LMG  with  bit  7  set  to  1  and  the  command  number  In  bit  JS  -  bit  6. 

2)  Address  FD  hex  Is  written  by  the  LM  with  the  resulting  command  status 
code. 

Bit  7  of  address  FF  hex  Is  used  as  a  semaphore  and  set  to  1  by 
the  LMG  when  a  command  Is  written  and  Is  cleared  to  ^  by  the  LM  to  acknow¬ 
ledge  receipt  of  the  command.  The  sequence  of  events  In  a  command  handshake 


Is  as  follows: 


CMOAOR 

DXCMO 

CMOSTS 

DXSTS 

ST8ALR 

LMSTS 


LASTS 


HWTST 


LMBUF 


lOBUFI 


iOBUFB 


■  -  ■-  ••-fc.k-.' 


Figur*  28  SM  Memory  Mop 


1)  LMG  writes  into  address  FF  hex  with  bit  7  set  to  1  and  the 
command  nuiid>er  In  bits  ^  through  6. 

2)  This  generates  an  Interrupt  In  the  LM.  The  Interrupt  routine 
clears  bit  7,  checks  the  validity  of  the  command  number,  and 
writes  an  Intermediate  status  code  'command  received'  (+1) 
Into  address  FD  hex. 

3)  When  the  Command  Interpreter  executes.  It  changes  the  Inter¬ 
mediate  status  to  'command  active'  (+2)  In  address  FD  hex. 

4)  When  the  Conmand  Interpreter  completes  execution  of  the  com¬ 
mand  it  writes  the  final  status  code  or-n)  into  address 
FD  hex. 

2. 3. 6. 4. 2  Data  Transfer  Protocol 

Data  transfers  take  place  between  the  LMG  and  a  subsystem.  The 
software  performing  this  In  the  LM  is  a  nonresident  task  loaded  from  either 
the  LMG  or  the  NF.  The  nonresident  task  utilizes  the  SMHMD  to  make  data 
transfers  to  or  from  SM.  Three  bytes  in  SM  are  used  In  the  data  transfer 
handshakes:  1)  Address  FE  hex  written  by  LMG  to  cause  LM  to  manipulate 
handshake  bits,  2)  Address  FC  hex  contains  the  buffer  control  bits,  and 
3)  Address  FB  hex  contains  the  byte  count  for  data  transfers.  There  are 
four  types  of  data  transfers:  Sequential  Input  (SEQIN) ,  Refreshed  Input 
(REFIN),  Sequential  output  (SEQOUT) ,  Refreshed  output  (REFOUT).  Following 
Is  the  handshake  sequence  for  each  of  these. 

SEQIN:  1)  Nonresident  task  calls  the  SMHND  function  SEQPUT  to  put  a 

buffer  of  data  Into  SM. 


2)  SMHND  transfers  data  and  byte  count  from  task  buffer  into  SM. 

3)  SMHND  sets  RDYl  (b7  In  FC)  -  1. 

4)  SMHND  sets  asynchronous  service  request  (b7  in  FA) . 

5)  SMHND  returns  'pending*  (+1)  status  to  nonresident  task. 

6)  LMG  clears  asynchronous  service  request  (b7  in  FA). 

7)  LMG  requests  the  buffer  (if  RDY1*1,  then  RDYlagf  and  REQ1=1) . 

8)  LMG  reads  the  byte  count  and  data  from  SM. 

9)  LMG  issues  STATUS  function  conmand  to  LM. 

10)  LM  CMDITR  function  STATUS  clears  REQl  to  0. 

11)  Nonresident  task  calls  the  SMHND  function  SIREAD  to  check 

REQl  bit.  Transfer  is  complete  when  has  been  cleared 

to  f). 

REFIN:  1)  Nonresident  task  calls  SMHND  function  REFPUT  to  put  a  buffer 

of  data  into  SM.  If  REQ1=1  then  'pending'  (+1)  status  is 
returned  to  nonresident  task  and  task  relinquishes  CPU  con¬ 
trol  to  try  again  soon. 

2)  SMHND  clears  RDYl  to  0. 

3)  SMHND  transfers  data  and  byte  count  from  task  buffer  into  SM. 

4)  SMHND  sets  RDY=1. 

5)  SMHND  returns  'success'  (0)  status  to  nonresident  task. 

6)  LMG  requests  buffer  (if  RDYl-1  then  RDY1*G  and  REQ1»1) . 

7)  LMG  reads  byte  count  and  data  from  SM. 

8)  LMG  writes  DXCMD  (address  FE  hex)  -  03  causing  an  interrupt 
to  the  LM. 

9)  LM  interrupt  routine  sets  REQl-0  and  RDYl-1. 
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SEQOUT:  1)  LMG  requests  buffer  (if  then  RDY0*0  and  REQ0“1). 

2)  LMG  writes  byte  count  and  data  Into  SM. 

3)  LMG  writes  DXCMD  (address  FE  hex)  =  causing  interrupt  to 

the  LM. 

4)  LM  interrupt  routine  sets  REQ0=0  and  internal  'DATRDY'  flag=l. 
3)  Nonresident  task  calls  SMHND  function  SEQGET  to  get  data. 

If  DATRDY  =  j6  then  'pending'  (+1)  status  Is  returned  to  the 
nonresident  task  and  the  task  relinquishes  CPU  control  to 
try  again  soon. 

6)  SMHND  transfers  data  and  byte  count  to  task  buffer. 

7)  SMHND  clears  internal  DATRDY  flag  to  /9. 

8)  SMHND  sets  RDY0=1. 

9)  SMHND  returns  'success'  (0)  status  to  nonresident  task. 

REFOUT:  1)  LMG  requests  buffer  (If  RDY^=1  then  RDY0»0  and  REQ0=1). 

2)  LMG  writes  byte  count  and  data  Into  SM. 

3)  LMG  writes  DXCMD  (address  FE  hex)  -  01  causing  interrupt  to 

the  LM. 

4)  LM  interrupt  routine  sets  RDY0=1  and  REQ0«0. 

5)  Nonresident  task  calls  SMHND  function  REFGET  to  get  data. 

If  REQ0“1  then  'pending'  (+1)  status  is  returned  to  the  non¬ 
resident  task  which  relinquishes  CPU  control  to  try  again 
soon. 

6)  SMHND  sets  RDY0-O. 

7)  SMHND  transfers  data  and  byte  count  to  task  buffer. 

8)  SMHND  sets  RDY0-1. 

9)  SMHND  returns  'success'  (0)  status  to  nonresident  task. 


80 


2.3.7 


INTERRUPT  SERVICE  ROUTINE 


The  LM  Motorola  6800  processor  has  three  different  types  of  in¬ 
terrupts:  Reset,  Nonmaskable  Interrupt  (NMl) ,  and  Interrupt  Request  (IRQ). 
Reset  is  used  during  power  up  or  as  a  result  of  the  reset  pushbutton  being 
depressed.  This  action  causes  the  hardware  to  be  Initialized  and  the  soft¬ 
ware  to  execute  from  an  Initialization  program.  NMI  is  not  used.  IRQ  is 
the  only  remaining  interrupt  source  and  is  used  to  service  all  system 
interrupts.  Interrupts  are  enabled  by  clearing  the  interrupt  mask  bit  in 
the  condition  code  register  (6800  instruction  CLI).  Execution  of  the  inter¬ 
rupt  service  routine  (INT)  takes  place  whenever  interrupts  are  enabled  and 
IRQ  pin  goes  low. 

The  sources  for  an  IRQ  are  listed  in  Table  12.  There  is  a  sub¬ 
routine  to  service  each  of  these  sources  and  INT  makes  a  call  to  each  of 
these  as  shown  in  Figure  29.  Since  each  subroutine  is  called  for  every 
interrupt,  each  subroutine  must  check  for  its  interrupt  conditions  and 
simply  return  immediately  if  its  execution  is  not  required. 

All  machine  registers  are  automatically  saved  by  the  6800  hardware 
upon  an  interrupt  and  are  automatically  restored  upon  execution  of  a  Return 
from  Interrupt  (RTI)  instruction.  A  detailed  description  of  the  interrupt 
routines  is  presented  in  Appendix  C,  Section  2-G. 

2.3.8  COMMAND  INTERPRETER 

The  Command  Interpreter  (CMDITR)  task  runs  in  the  LM  and  inter¬ 
prets  twelve  (12)  distinct  commands  from  the  LMG.  These  commands  are  listed 
with  a  short  description  in  Table  13.  The  LMG  Issues  a  command  by  writing 
the  corresponding  code  into  the  command  byte  (address  FF)  in  shared  memory. 
Status  of  the  command  is  returned  to  the  LMG  in  the  command  status  byte 
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Table  12 


IRQ  SOURCES 


Table  13 


IM  COMMANDS 


PRGMLD 

81 

Load  non-resident  task. 

RUN 

82 

Run  non-resident  task. 

STOP 

83 

Stop  non-resident  task. 

NPDIAG 

84 

Saune  as  NPINIT. 

85 

Reserved. 

CANCEL 

86 

Cancel  the  previous  cmd.  that  is  pending. 

XFRTBL 

87 

Transfer  LM  system  tables  to/from  IMG. 

STATUS 

88 

Clear  input  buffer  request  bit. 

RESET 

89 

Resets  CMDITR  and  ICA. 

RESTRT 

8A 

Jximp  to  power  up  restart  location. 

NPINIT 

8B 

Request  NPMND  to  initialize  NP's. 

CONFIG 

8C 

Configure  selected  subsystem. 

NOOP 

8D 

No  operation. 
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(address  FD)  In  shared  memory  and  are  listed  In  Table  14.  The  commands 
are  mutually  exclusive  and  a  new  command  may  not  be  Issued  until  the  previous 
command  has  been  completed,  with  the  exception  of  CANCEL  and  RESTRT,  which 
may  be  Issued  anytime. 

The  command  interpreter  task  shown  in  Figure  30  works  in  con¬ 
junction  with  the  LM  function  interrupt  routine  shown  in  Figure  31.  When 
the  LMG  writes  into  the  comnand  byte  in  shared  memory,  the  resulting  interrupt 
Initiates  the  LM  function  Interrupt  routine.  The  routine  checks  the  command 
for  validity  or  express  (CANCEL,  RESTRT)  and  then  does  one  of  four  things, 
depending  upon  the  connand  and  the  state  of  the  command  Interpreter  task: 

1)  If  the  command  is  express  (ie  CANCEL  or  RESTRT),  then  it  is  executed  to 
completion;  2)  if  a  previous  command  is  in  progress,  then  an  error  status 
(-2)  is  returned  to  the  LMG;  3)  if  the  command  is  Invalid, then  an  error  status 
(-1)  Is  returned  to  the  LMG;  4)  otherwise,  a  flag  is  set  up  for  the  command 
interpreter  task  to  recognize  and  begin  execution.  A  'command  received' 
status  is  returned  to  the  LMG. 

The  command  Interpreter  task  in  its  quiescent  mode  continually 
checks  for  the  new  comnand  flag  set  by  the  LM  function  Interrupt  routine 
and  relinquishes  CPU  control  if  the  flag  is  not  set.  When  the  flag  is 
found  set,  the  command  status  to  the  LMG  is  changed  from  'command  received' 
to  'command  active'.  The  Interpreter  task  then  calls  one  of  twelve  command 
modules  which  return  with  a  module  status.  This  status  is  copied  to  the 
command  status  in  shared  memory  and  the  new  command  flag  is  cleared.  The 
Interpreter  task  then  returns  to  its  quiescent  mode  waiting  for  another 
comnand. 

A  description  of  each  of  the  twelve  commands  will  now  be  pre¬ 
sented. 
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Table  14 


CMDITR  STATUS  RETURN  CODES 


Comnand 

Status 

Indication 

General 

+2 

Command  active. 

♦1 

Command  received. 

a 

Success . 

-1 

Invalid  command. 

-2 

Another  ccmnumd  still  in  progress. 

-3 

Command  not  implemented  yet. 

-4 

Ccxnmand  cancelled. 

PRGMLD 

-10 

#  of  bytes  not  from  -1  to  +61. 

-11 

Existing  non-resident  task  is  not  dormant. 

-12 

TYPE  not  0  or  1. 

-13 

SOURCE  not  0  or  1. 

-15 

XFR  or  TRLR  record  with  SOURCE  »  NP. 

-16 

Invalid  start  address. 

-17 

Invalid  end  address. 

-18 

XFR  record  with  no  HDR  record. 

-19 

TRLR  record  with  no  XFR  record. 

-20 

EXEC  failure  to  REMOVE  previous  task. 

-21 

NP  failure  to  upload  task. 

-22 

EXEC  failure  to  INSTAL  NP  task. 

-23 

Program  checksum  not  zero. 

-24 

EXEC  failure  to  INSTAL  IMG  task. 

RUN 

-10 

A  task  is  not  installed. 

-11 

The  task  is  not  dormant. 

-12 

Task  checksum  not  zero. 

STOP 

-10 

A  task  is  not  installed. 

-11 

The  task  is  dormant. 

-12 

Failure  to  STOP  after  5  sec. 

NPDIAG 

- 

see  NPINIT. 

CANCEL 

- 

None 

XFRTBL 

-10 

Invalid  table  number. 

-11 

To/from  LM  not  0  or  1. 

-12 

#  bytes  not  from  1  to  64. 

-13 

Offset  <0. 

-14 

Attempt  to  write  a  read  only  table. 

-15 

TIME:  <  bytes  too  large. 

-16 

TIME:  Offset  too  large. 

-17 

NPREC:  Function  not  0  to  5. 

-18 

NPREC:  Invalid  #  bytes. 

-19 

SICSTS:  Table  shows  <1  «  of  HP's. 

-20 

SICSTS:  Table  shows  >20  #  of  NP's. 
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Table  14  <cont.) 


CMDITR  STATUS  RETURN  CODES 


Conmand 

Status 

Indication 

XFRTBL 

-21 

NPHND  error. 

-22 

ICCNPG:  ICAHND  error  GRP  A. 

-23 

ICCNFG:  ICAHND  error  GRP  B. 

STATUS 

- 

None 

RESET 

-10 

ICAHND  fail  to  reset  ICA. 

RESTRT 

- 

None 

NPINIT 

-10 

NPHND  error. 

CONFIG 

-10 

SOURCE  not  0  or  1  (LMG  or  NP) . 

-11 

GROUP  not  1  or  2  (A  or  B) . 

-12 

ICAHND  error. 

-13 

NPHND  error. 

-14 

Invalid  HP  table. 

NOOP 

None 

CMDITR 


COMMENTS 


RELINQ 


WAIT  FOR  NEW  COMMAND 
FLAG  WHICH  IS  SET  BY 
LMFI  WHEN  A  NEW  CMD 
IS  RECEIVED  FROM  THE 


SEND  'CMD  active' 
TO  LMG. 


GO  TO  THE  COMMAND  ROUTINE 


13  COMMAND  TABLE 
ENTRIES.  ONLY  THOSE 
LABELED  'nOEXPR'  ARE 
DONE  HERE. 

EACH  ROUTINE  RETURNS 
WITH  CMD  STATUS. 


SEND  CMD  STATUS 
TO  LMG. 

CLEAR  NEW  CMD  FLAG. 


Figure  30  CMDITR  Flowchart 
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PRGMLD  (Program  Load)  Is  command  nundjer  81  hex.  This  command  Is 
used  to  load  programs  Into  the  nonresident  task  area  In  the  LM  from  either 
the  NP  or  the  LMG  and  then  to  Install  the  loaded  program  as  a  task  with  the 
executive. 

RUN  (Run  nonresident  task)  is  command  number  82  hex.  This  com¬ 
mand  Is  used  to  activate  the  nonresident  task  for  running  as  part  of  the 
real-time  system. 

STOP  (Stop  nonresident  task)  Is  command  number  83  hex.  This  com¬ 
mand  Is  used  to  stop  the  execution  of  the  LM  nonresident  task. 

NPDIAG  (NP  diagnostic)  Is  command  number  84  hex.  This  command  is 
used  to  cause  the  Nameplates  to  run  their  Internal  diagnostics.  NPDIAG  Is 
Identical  to  NPINIT  and  Is  Implemented  as  a  jump  to  NPINIT. 

Command  number  85  hex  Is  reserved. 

CANCEL  (Cancel)  Is  command  number  86  hex.  This  command  is  used 
to  stop  the  execution  of  any  other  command  module  already  In  progress. 

XFRTBL  (Transfer  table)  Is  command  number  87  hex.  This  command 
Is  used  to  transfer  all  or  part  of  any  one  of  eleven  LM  tables  to  or  from 
the  LMG. 

STATUS  (Status)  Is  command  number  88  hex.  This  command  Is  used 
to  assist  In  the  data  transfer  handshake  for  sequential  Input  to  the  LMG 
by  clearing  the  REQl  bit  In  the  SI  byte  in  SM  (address  FC  hex) . 

RESET  (Reset)  is  command  number  89  hex.  This  command  is  used  to 
reset  the  state  of  the  CMDITR  task  and  the  ICA  hardware. 

RESTRT  (Restart)  Is  command  number  8A  hex.  This  command  Is  used 
to  cause  the  LM  to  jump  to  Its  power  up  restart  location. 

NPINIT  (NP  Initialization)  Is  command  number  8B  hex.  This  com- 


mand  Is  used  to  cause  the  NFHND  to  reset  all  the  MF's,  assign  addresses  to 
the  NP^s,  and  cause  each  NP  to  run  Its  Internal  diagnostic. 

CONFIG  (ICA  configure)  Is  connand  number  8C  hex.  This  command 
when  used  causes  the  ICAHND  to  configure  either  group  A  or  group  B  of  the 
ICA  with  configuration  parameters  from  either  the  LMG  or  the  NP. 

NOOP  (No  operation)  Is  command  number  8D  hex.  This  command  Is 
used  to  provide  the  LMG  with  means  of  exercising  the  command  handshake 
without  causing  anything  to  happen. 

The  parameters  associated  with  each  command  are  listed  in  Table 
13.  Interactions  with  the  rest  of  the  system  are  shown  In  Figure  32. 
Refer  to  the  User's  Manual  for  more  detail  on  usage  of  the  commands.  Refer 
to  Appendix  C,  Section  2-H. 

2.3.9  NONRESIDENT  SOFTWARE 

The  LM  has  2K  bytes  of  read/write  memory  (addresses  0400  to  idBFF) 
allocated  for  loading  external  programs  for  execution.  An  external  program 
may  be  either  uploaded  from  a  subsystem  nameplate  or  downloaded  from  the 
LMG.  Although  there  are  many  types  of  programs  (data  I/O,  subsystem  diag¬ 
nostic,  calibration),  only  one  program  may  be  loaded  at  any  one  time.  This 
program  Is  treated  as  an  independent  task. 

A  typical  LMG  command  sequence  to  the  LM  might  be  as  follows: 

1)  Issue  command  STOP  to  halt  the  present  nonresident  task. 

The  STOP  command  module  will  set  a  STPRQ  flag  for  the  NRTSK 
to  executive  request  EXIT. 

2)  Issue  command  PRGMLD,  which  will  load  an  external  program 
Into  the  LM  nonresident  task  area  from  either  the  NP  or  the 
LMG.  The  PRGMLD  coimnand  module  will  perform  the  following 


Table  15 


m  COMMAND  PARAMETERS 

PRGMLD  header  record:  60  -  FT 

81  -  TYPE  00  -  1/0  program 

01  -  DIAG  program 

82  -  SOURCE  00  ~  UIG 

01  -  NP 

PRGMLD  transfer  record:  80  -  #  bytes,  01  to  3D 

81  -  starting  load  address,  high  byte 

82  -  starting  load  address,  low  byte 

83  to  BF  -  program  bytes 

PRGMLD  trailer  recoru:  80  -  00 

81  -  program  checksum 

XFRTBL:  80  -  table  #,  01  to  0B 

81  -  #  bytes 

82  -  offset  into  table 

83  -  to/from  00  -  LM  to  UIG 

01  -  UIG  to  LM 

84  to  BF  -  table  loaded  by  LM  or  LMG  depending  on  to/from 

byte 

CONFIG:  80  -  SOURCE  00  -  IMG 

01  -  NP 

81  -  GROUP  01  -  GRPA 

02  -  GRPB 

82  to  89  -  configuration  data  if  from  LMG 
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LM 

FUNCTION 

INTERRUPT 


Figure  32  Command  Interpreter  Interactions 
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functions : 


a)  Request  the  executive  to  REMOVE  the  previous  task  from 
the  active  task  list. 

b)  Load  the  new  program  Into  the  nonresident  task  area. 

c)  Verify  the  new  program's  checksum. 

d)  Request  the  executive  to  INSTAL  the  new  task  on  the 
active  task  list. 

3)  Issue  command  RUN  to  start  the  nonresident  task.  The  RUN 
command  module  will  Issue  the  executive  request  ACTVAT. 

The  nonresident  task  may  use  resident  LM  resources.  These  include 
SM,  ICA,  and  NP  handlers,  data  and  time  of  day,  and  In  particular  executive- 
supplied  math  functions.  As  an  example,  for  this  demonstration  there  Is  a 
synchro  Input/output  task  which  when  running  requires  the  following  services 
and  resources: 

EXECRQ  ICARQ  for  synchro  input  voltages. 

EXECRQ  MATH  for  voltage  checks  and  calculations. 

EXECRQ  ICARQ  for  synchro  output  voltages. 

EXECRQ  SMRQ  to  send  degrees  data  to  LMG. 

EXECRQ  DELAY  for  loop  timing  between  outputs. 

EXECRQ  SICRQ  to  record  errors. 

TIME  to  record  time  of  error. 

In  order  to  properly  load  and  execute  a  nonresident  task,  the  first 
thirteen  bytes  of  the  nonresident  task  must  be  a  header  of  the  form: 


1)  to  6)  Program  name  -  6  ASCII  characters 


7)  Start  address  H 


8)  Start  address  L 

9)  End  address+1  H 

10)  End  address+1  L 

11)  Initial  stack  pointer  H 

12)  Initial  stack  pointer  L 

13)  Reserved  for  insertion  of  program  checksum 

These  parameters  are  used  by  the  system  during  both  loading  and  activation 


for  execution. 


SECTION  3 


INTERFACE  CONFIGURATION  ADAPTER 

The  Interface  Configuration  Adapter  (ICA)  Is  the  component  that  pro¬ 
vides  the  LM  with  its  universal  interfacing  capability.  The  RLU,  working 
with  Electronic  Nameplates,  can  Identify  interfaced  subsystems  and  auto¬ 
matically  configure  the  ICA  with  the  appropriate  electrical  Interface. 

The  ICA  can  be  used  with  a  wide  variety  of  I/O  signal  types.  The 
interface  consists  of  two  groups  of  four  I/O  channels.  Each  group  can  be 
independently  programmed  to  support  either: 

1)  4  AC  or  DC  analog  input  or  output  lines,  or 

2)  4  parallel  digital  input  or  output  lines,  or 

3)  1  serial  synchronous  digital  input  or  output  channel  with 
handshaking,  or 

4)  1  synchro  input  or  output  channel,  or 

5)  a  variety  of  self-test  terminations. 

The  ICA  can  be  described  in  terms  of  the  following  7  major  hardware 
sections: 

1)  Signal  input  and  output  (SIO)  channels  for  Group  A. 

2)  SIO  channels  for  Group  B. 

3)  Reference  Generation  (shared  by  both  groups). 

4)  Address  decoding  and  configuration  control  (ADCC)  for  Group  A. 

5)  ADCC  for  Group  B. 

6)  Serial  Input  and  output  (SERIO)  circuitry  for  Group  A. 

7)  SERIO  circuitry  for  Group  B. 
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These  sections  and  their  interconnections  are  indicated  in  Figure  33. 

3.1  SIGNAL  I/O  CHANNEL  DESIGN 

A  block  diagram  of  a  signal  input/output  (SIO)  channel  is  shown  in 
Figure  34.  The  channel  provides  the  required  functions  of  digital- to- 
analog  conversion,  analog- to-digital  conversion,  amplification,  buffering, 
sampling  and  logic  level  processing.  The  SIO  channels  Interface  to  the  LM 
through  several  control  lines,  read/write  strobe  lines  and  the  ICA  bus. 

The  SIO  topology  is  unique  in  that  it  provides  a  signal  wrap  around 
feature.  Each  SIO  channel  contains  an  ADC  which  is  continuously  updated 
at  anSOO  samples  per  second  rate.  This  ADC  can  be  read  at  any  time  by  the 
LM  to  measure  the  input  level  if  the  SIO  channel  is  programmed  for  input 
or  to  measure  the  output  level  if  the  SIO  is  programmed  for  output. 

The  input  and  output  functions  are  completely  independent  in  the  SIO, 
sharing  only  the  common  subsystem  bound  I/O  lines  (+/-).  With  the  SIO 
channel  programmed  for  output  the  input  can  be  used  to  perform  several 
Internal  test  functions  or  to  monitor  the  output.  The  output  can  be  pro- 
granmed  as  single-ended  (with  the  return  through  the  SIO  ground  line)  or 
as  differential.  This  programming  has  no  effect  on  the  input  configuration. 

The  output  signal  is  derived  from  one  of  three  sources: 

1)  the  output  DAC, 

2)  the  group  HILEVEL  signal  line,  or 

3)  the  group  LOLEVEL  signal  line. 

This  selection  is  through  the  output  MUX  as  shown  in  the  Figure  34  .  Ad¬ 

dressing  of  the  MUX  is  controlled  by  the  ADCC  section  of  the  ICA.  For 
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analog  output,  the  output  DAC  is  selected.  The  reference  applied  to  the  DAC 
originates  In  the  ADCC  section  of  the  ICA.  For  DC  outputs  the  DAC  reference 
Is  10  volts.  For  AC  outputs  the  DAC  reference  Is  a  400  Hz  slnewave  of  fixed 
amplitude.  For  digital  output  the  MUX  Is  addressed  to  the  programmed  HI  or 
LO  logic  level  depending  upon  the  desired  output  logic  signal. 

Digital  Inputs  are  processed  through  the  normal  Input  MUX  and  Differen¬ 
tial  Amplifier.  The  logical  threshold  Is  programmed  for  the  group  as  the 
THRESLEVEL  shown  In  the  Figure  34.  Following  level  slicing,  the  logic 
Input  Is  processed  and  made  available  to  the  LM  on  the  DIGIN  line.  This 
section  Is  always  operational  so  that  simple  level  detection  can  be  accom¬ 
plished  in  either  the  digital  or  analog  modes. 

Appendix  B,  Section  3-A  contains  a  detailed  schematic  of  the  Signal  I/O  channel 
and  will  be  referred  to  In  the  discussion  below.  The  discussion  will  focus 
on  the  operation  of  Channel  H  but  will  of  course  be  applicable  to  each  of 
the  four  channels  In  a  group. 

3.1.1  ANALOG  INPUT  PROCESSING 

The  analog  Input  signal  processing  Is  accomplished  by  the  Input 
multiplexer  Ml,  the  Input  amplifier  M2,  the  track  and  hold  circuitry  con¬ 
sisting  of  MIS  and  H8  and  the  channel  analog  to  digital  converter  (ADC) 

Mil. 

The  Input  multiplexer  Is  programmed  to  either  address  3  or  7  to 
allow  Input  signals  to  reach  the  input  amplifier.  Note  that  the  Input 
amplifier  Is  an  instrumentation  amplifier  capable  of  Implementing  either  a 
single-ended  amplifier  or  a  differential  amplifier.  Address  3  results  In 
a  single-ended  Input  with  the  positive  (+)  Input  lead  going  to  the  positive 
Input  of  the  amplifier  and  the  negative  (-)  input  lead  being  open  circuited. 


The  signal  return  Is  assumed  to  be  provided  via  the  group  signal  return  line 
of  the  Interface  cable.  Additionally  address  3  uses  the  multiplexer  to 
ground  the  negative  Input  of  the  amplifier.  Address  7  results  In  a  differ¬ 
ential  Input  configuration  with  the  +  Input  lead  going  to  the  +  Input  of  the 
amplifier  and  the  -  Input  lead  going  to  the  -  input  of  the  amplifier. 

The  common  mode  limit  of  the  input  amplifier  (+/-  10  volts)  must 
be  observed  by  any  Input  signals.  The  amplifier  Is  protected  from  overloads 
at  the  Input  by  the  protectlor  circuitry  of  Rl,  R2  and  D1-D4.  The  amplifier 
provides  a  gain  of  one  to  any  differential  signal  applied  to  its  Inputs. 

The  conmon  mode  rejection  ratio  of  the  input  amplifier  is  specified  as 
greater  than  70  dB  at  a  gain  of  one.  The  input  impedance  of  the  input 
amplifier  Is  greater  than  3xl0**9  ohms.  The  amplifier  output  is  applied 
to  the  input  of  the  track  and  hold  circuit. 

The  track  and  hold  circuit  provides  the  signal  processing  required 
by  the  analog  to  digital  converter.  For  DC  input  signals  the  track  and  hold 
circuit  is  used  in  a  conventional  manner.  The  +/-  line  from  the  ADCC  sec¬ 
tion  is  held  in  the  +  state  which  results  in  the  track  and  hold  circuit 
having  a  gain  of  one  when  in  the  track  mode.  The  signal  is  sampled  and  the 
sample  converted  by  the  ADC  at  an  800  samplesper  second  rate.  The  hold/ 
track  modes  are  controlled  by  the  H/T  line  from  the  ADCC.  For  AC  signals 
the  +/-  line  is  used  to  invert  the  gain  of  the  track  and  hold  circuit  at  an 
800  Hz  rate.  The  gain  is  made  positive  during  the  positive  half  cycle  of 
the  ICA  400  Hz  reference  signal  and  is  made  negative  during  the  negative 
half  cycle.  The  H/T  signal  takes  a  sample  at  the  positive  and  negative 
peak  of  each  cycle  of  the  400  Hz  reference.  If  the  input  AC  signal  is 
derived  from  the  ICA  400  Hz  reference  the  circuit  operation  results  in 
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sampling  the  peak  value  of  the  input  waveform  and  obtaining  a  sample  whose 
polarity  is  indicative  of  the  phase  of  the  input. 

The  AOC  chip  used  is  designed  to  accept  inputs  of  0  to  +  5  volts 
and  to  provide  a  straight  binary  conversion  on  these  inputs.  The  ICA  is 
designed  to  process  signals  in  the  range  of  +/-  10  volts.  The  output  of 
the  track  and  hold  circuit  is  scaled  by  resistors  R13,  R14,  and  R15  to 
accommodate  the  ADC  input  requirements.  The  ADC  output  count  relates  to 
the  input  voltage  through  the  formula 


*  -12.8  +  0.1* (COUNT) 
In 


The  correspondence  between  significant  voltages  and  counts  are  given  below. 


Voltage 


Count 

Decimal 

Hexadecimal 

0 

a 

28 

1C 

128 

60 

228 

E4 

255 

FF 

0.0 

+10.0 

+12.7 


The  AOC  runs  continuously  in  any  of  the  ICA  modes.  The  ADC  chip 
has  an  Internal  register  which  is  updated  at  the  800  Hz  sampling  rate  de¬ 
scribed  above  and  which  can  be  accessed  at  any  time  by  the  LM. 

3.1.2  DIGITAL  INPUT  PROCESSING 

Digital  inputs  are  processed  through  the  input  amplifier  M2  in 


the  same  manner  as  are  analog  Inputs.  This  provides  for  a  high  input 
impedance  for  the  digital  input  as  well  as  the  capability  of  either  single 


ended  or  differential  processing  as  described  above.  The  output  of  the 
Input  amplifier  Is  connected  to  an  analog  comparator  M7.  The  comparison 
threshold  Is  programmed  In  the  reference  generation  circuitry  described  In 
Section  3.2.  The  comparison  threshold  can  be  programmed  between  +/-  10 
volts.  This  allows  the  ICA  to  process  Inputs  from  virtually  any  standard 
logic  family.  The  resulting  logic  states  at  the  output  of  M7  reflect 
whether  the  input  Is  above  (logic  one)  or  below  (logic  zero)  the  programmed 
threshold  value.  Negative  logic  can  be  Interpreted  by  proper  handling  in 
the  LM  via  programs  In  the  Electronic  Nameplate. 

Logic  processing  circuitry  for  the  SIO  channel  consists  of  M9  and 
MIO  which  can  be  programmed  to  two  distinct  modes.  In  the  follow  mode  the 
output  of  the  comparator  Is  continuously  sampled  at  a  500  KHz  rate  by  M9A. 
The  Q  output  of  M9A  is  multiplexed  to  the  DIGIN-OR  line  by  MIO  and  is  read¬ 
able  by  the  LM  by  means  of  circuitry  described  In  Section  3.3  below.  The 
DIGIN-OR  line  simply  represents  the  most  recent  sample  of  the  comparator 
output  and  will  follow  this  output  continuously.  In  the  latch  mode  the 
sampled  comparator  output  Is  used  In  latch  M9B.  If  the  Input  crosses  the 
programmed  comparlsc.i  threshold  from  above  M9B  will  be  set.  The  state  of 
M9B  is  multiplexed  to  the  DIGIN-OR  line  by  MIO  and  Is  readable  as  before. 
Each  time  the  four  DIGIN  lines  of  a  group  are  read  by  the  LM,  circuitry  In 
the  ADCC  section  of  the  ICA  resets  the  Input  latches  (register  M9B)  for  the 
entire  group.  This  mode  Is  designed  to  process  momentary  signals  such  as 
produced  by  contact  closures. 

3.1.3  CONTACT  CLOSURE  PROCESSING 

Contact  closures,  either  floating  or  to  ground,  can  be  detected 
In  either  of  the  two  modes  described  in  Section  3.1.2. 


For  floating  contacts,  a  differential  input  is  configured  by  the 
input  MUX  Ml  and  the  internal  Thevenln  sources  are  placed  on  the  I/O  lines 
by  activating  analog  switch  M3.  This  results  in  a  balanced  +/-  5  volt 
source  with  a  6.7  K  ohm  source  Impedance  which  is  applied  across  the  input 
leads.  If  a  contact  is  closed  across  the  input  pair  the  input  voltage  is 
reduced  from  10  volts  to  0  volts.  A  programmed  threshold  of  5  volts 
applied  to  M7  will  result  in  the  state  of  the  contacts  being  represented 
by  the  logic  level  at  the  output  of  M7.  This  level  can  be  processed  as 
any  other  digital  input. 

Contacts  to  ground  are  processed  by  selecting  a  single-ended 
input  configuration  and  setting  the  logic  threshold  to  2.5  volts.  The  ex¬ 
ternal  contact  Is  placed  from  the  +  lead  to  ground  and  sees  a  Thevenln 
source  in  the  ICA  of  5  volts  and  3.33  K  ohms.  The  contact  closure  reduces 
the  output  of  M2  from  +5  volts  to  0  volts. 

3.1.4  ANALOG  OUTPUT  PROCESSING 

The  analog  output  signal  processing  is  accomplished  by  the  output 
digital- to-analog  converter  (DAC)  components  M13  and  M14,  the  output  multi¬ 
plexer  M12  and  the  output  buffer  amplifiers  comprised  of  M4,  M3  and  M6. 

The  analog  output  value  is  determined  by  two  parameters  which  are  input  to 
the  DAC:  the  output  signal  type  (DC  or  AC)  determined  by  the  reference 
input  to  the  DAC  and  the  output  signal  amplitude  determined  by  the  digital 
input  to  the  DAC.  The  DAC  is  a  four  quadrant  multiplying  type  and  as  such 
can  provide  output  signals  of  the  form 

-  Vref*  (128-COUNT) /128 

where  Vref  is  the  reference  voltage  applied  to  the  DAC  and  COUNT  is  the 
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value  of  the  digital  Input  to  the  DAC.  COUNT  Is  Interpreted  as  varying 
between  +127  and  -128  (offset  binary).  The  table  below  Illustrates  the 
correspondence  between  COUNT  and  special  voltage  values. 


For  single-ended  DC  output  the  reference  voltage  Vref  Is  set  to 
+10.00  volts.  The  available  analog  output  ranges  from  -9.92  to  +10.00 
volts.  The  single-ended  state  Is  detected  In  the  ADCC  circuitry  by  '^glc 
which  determines  the  number  of  output  buffer  amplifiers  which  are  enabled 
(one  =>  single-ended,  2  «>  differential  outputs).  When  two  channel  buffers 
are  enabled,  the  value  of  the  voltage  Vref  Is  reduced  to  +5.00  volts.  The 
differential  output  ranges  from  -9.92  to  +10.00  volts.  For  single-ended 
AC  outputs,  Vref  Is  a  20  volt  P-P  slnewave  at  400  Hz.  This  allows  the 
output  to  range  from  0  to  20.00  volts  P-P  at  0  degrees  phase  shift  relative 
to  the  reference  and  from  0  to  19.84  volts  P-P  at  180  degrees  phase  shift 
relative  to  the  reference.  For  a  differential  output  configuration,  Vref 
Is  reduced  to  a  10  volt  P-P  slnewave  at  400  Hz,  providing  the  same  output 
range  as  the  single-ended  configuration. 

When  the  ICA  Is  configured  for  analog  output  the  DAC  output  Is 
routed  to  the  output  buffers  through  M12.  This  Is  accomplished  by  address¬ 
ing  M12  with  address  3.  The  logic  for  addressing  M12  Is  In  the  ADCC  section 


of  the  ICA. 


The  buffer  amplifiers  consist  of  M4,  M5,  M6  and  their  associated 
circuitry.  These  amplifiers  must  provide  a  very  low  output  Impedance  to 
drive  the  subsystems  and  yet  must  be  controllable  so  that  they  present 
essentially  an  open  circuit  when  the  channel  Is  used  for  Input.  The  re¬ 
quirement  for  low  output  Impedance  prevents  the  use  of  a  conventional 
analog  multiplexer  to  connect  or  disconnect  the  buffer  from  the  Input /out¬ 
put  leads.  A  typical  electronic  analog  switch  has  an  on  resistance  of  100 
ohms,  which  Is  far  too  large  to  add  to  the  buffer  output  Impedance.  The 
circuit  used  solves  the  problem  by  utilizing  complementary  symmetry  output 
buffers  (Q1-Q2,  Q3-Q4)  Inside  the  loop  of  an  op-amp  stage  (M4A,  M4B).  The 
buffer  stage  Is  switched  In  and  out  of  the  op-amp  loop  by  analog  multi¬ 
plexers  M5,  M6.  The  op-amp  stages  retain  feedback  In  either  mode  through 
the  multiplexer.  Note  that  if  the  buffer  is  removed  from  the  op-amp  loop 
the  only  effect  on  the  Input/output  lines  is  a  small  leakage  current  (the 
difference  between  the  Icbo's  of  the  NPN  and  PNP  buffer  transistors).  When 
the  buffer  Is  activated  the  multiplexer  switch  resistance  Is  inside  the 
loop  of  the  op- amp  so  that  a  very  low  output  Impedance  Is  maintained.  The 
complementary  buffer  Is  biased  for  class  B  operation  and  as  such  can  con¬ 
tribute  crossover  distortion  to  high  frequency  AC  waveforms.  The  op-amp 
selected  has  a  slew  rate  of  13  v/ysec  and  at  400  Hz  the  crossover  distor¬ 
tion  Is  negligible. 

Analog  outputs  can  be  either  single-ended  or  differential  depend 
Ing  upon  the  programming  from  the  ADCC  section.  Each  buffer  amplifier 
(positive  and  negative)  Is  Individually  controllable.  As  mentioned  above. 


the  ADCC  logic  automatically  alters  the  output  DAC  reference  so  that  the 


output  range  Is  always  +/-  10  volts  for  either  single-ended  or  a  differen¬ 
tial  output  modes. 

3.1.5  DIGITAL  OUTPUT  PROCESSING 

Digital  output  levels  corresponding  to  the  two  binary  logic  states 
(one  and  zero)  are  prograomed  in  the  DAC's  located  in  the  reference  genera¬ 
tion  section  of  the  ICA.  These  levels  are  made  available  to  the  analog 
output  buffers  through  the  analog  multiplexer  M12.  Each  logic  level  can  be 
independently  programmed  to  a  value  in  the  range  of  +/-  10  volts.  This 
allows  interfacing  to  a  wide  range  of  logic  families  and  easily  implements 
a  negative  logic  scheme.  The  logic  In  the  ADCC  section  provides  proper 
addressing  to  multiplexer  M12  so  that  either  address  0  (corresponding  to 
the  value  programmed  for  a  logic  zero)  or  1  (corresponding  to  the  value 
programmed  for  a  logic  one)  is  selected  based  on  the  logic  level  programmed 
by  the  LM  for  each  group  channel.  Note  that  the  logic  levels  are  the  same 
for  all  channels  within  a  group. 

3.2  REFERENCE  GENERATION 

A  block  diagram  of  the  reference  generation  portion  of  the  ICA  is 
shown  in  Figure  35.  This  portion  generates  the  following  reference 
signals:  400  Hz  AC  reference  waveform,  +5.00  volt  DC(ADC  reference), 

+10.00  vdc,  +5.00  vdc,  20  vp-p  ac,  10  vp-p  ac(DAC  references),  HI,  LO,  and 
THREShold  levels  used  in  processing  digital  signals  in  the  SIO  groups. 

Appendix  b.  Section  3-B  contains  a  complete  schematic  and  parts  list  for  the 
ference  generation  section  which  will  be  referred  to  in  the  following 

discussion.  The  reference  generation  section  contains  portions  which  are 
shared  by  both  groups  and  portions  which  are  group  specific.  This  common¬ 
ality  will  be  pointed  out  in  the  following  sections. 


SINEWAVE 

SYNTHESIS 


Figure  35  Block  Diagram  of  a  Reference  Generation  System 


u 


3.2.1  400  Hz  AC  REFERENCE 

The  400  Hz  AC  reference  signal  is  used  to  generate  400  Hz  AC  out¬ 
put  signals  and  to  provide  timing  to  process  400  Hz  AC  Input  signals.  It 
Is  derived  from  the  LM  master  clock  (1  MHz)  by  direct  digital  synthesis. 

The  basic  timing  Is  accomplished  with  counters  Ml,  M2,  and  M3. 

Ml  and  M2  are  used  as  divide  by  5  counters,  resulting  in  40  KHz  at  the 
output  of  M2.  The  output  of  M3  Is  decoded  In  M5  at  a  count  of  50  and  reset 
resulting  in  a  total  division  of  50x5><5  or  1250  and  an  800  Hz  timing  signal, 
R800.  M7  contains  50  8-blt  samples  of  a  slnewave.  These  samples,  addressed 
at  0  through  49  within  the  ROM,  cover  one  half  cycle  of  the  sinewave.  The 
samples  are  applied  to  the  reference  DAC  (M8)  at  a  40  KHz  rate  so  that  each 
half  cycle  is  developed  in  1/800  second.  MlOA  and  M9B,  combined  with 
timing  through  M14A  and  M14B,  provide  synchronous  signal  inversion  so  that 
a  full  400  Hz  slnewave  results  at  the  output  of  M9B.  This  signal  is  used 
internally  as  the  AC  reference  for  various  DACs  and  is  made  available 
externally  through  the  ACREF  and  ACRET  lines  in  the  ICA/Subsystem  interface 
cable.  Q1  and  Q2  provide  signal  buffering  for  the  AC  reference. 

Timing  for  the  ADCs  in  the  SIO  channels  is  also  generated  in 
this  section.  The  outputs  from  M3  are  decoded  in  M6  at  a  count  of  25  to 
provide  the  H/T  timing  signal.  This  signal  results  in  the  track  and  hold 
circuit  entering  the  hold  mode  at  the  peak  of  the  ICA  reference.  Assuming 
that  there  is  no  phase  shift  between  the  generation  and  the  measurement  of 
the  reference,  the  ADC  will  digitize  a  peak  value  from  the  AC  waveform. 

The  signal  +/-  is  also  generated  in  this  section  (M14B,  M18C).  This  signal 
is  used  in  the  SIO  channel  to  synchronously  invert  AC  signals. 

The  400  Hz  reference  is  buffered  as  described  above  and  made 
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available  to  the  subsystem  through  connector  J4.  It  is  also  used  as  the 
group  analog  output  DAC  reference  when  the  group  Is  configured  for  AC  out¬ 
put.  The  full  20  vp-p  reference  is  used  for  the  single-ended  configuration 
and  a  10  vp-p  reference  is  used  for  differential  configurations. 

3.2.2  +10.00  AND  +5.00  vdc  REFERENCES 

M17A  and  its  associated  circuitry  are  used  to  generate  the  DC 
references.  The  output  of  M17A  is  a  constant  +10.00  volts,  calibrated  with 
R4.  M17B  provides  a  buffered  +5.00  volts  to  be  used  as  the  reference  volt¬ 
age  for  the  ADC's  located  in  the  SIO  channels.  The  DACs  in  the  SIO 
channels  of  Group  A  use  as  a  reference  the  output  of  M15A.  Group  B  DACs 
use  the  signal  from  M15B.  These  signals  can  be  a  constant  +10.00  volts,  a 
constant  +5.00  volts,  a  20  volt  p-p  400  Hz  slnewave  or  a  10  volt  p-p  400 
Hz  slnewave  depending  upon  the  exact  configuration  prograamed  into  the  ICA. 
Single-ended  DC  outputs  require  a  +10.00  volt  DAC  reference.  Differential 
DC  outputs  use  a  +5.00  volt  DAC  reference  so  that  the  amplitude  program¬ 
ming  is  the  same  for  both  single-ended  and  differential  configurations. 
Single-ended  AC  outputs  require  a  20  volt  p-p  DAC  reference  while  differen¬ 
tial  AC  outputs  use  a  10  volt  p-p  DAC  reference.  The  selection  logic  for 
Group  A  is  Implemented  with  M13A,  MllA,  M16A  and  M16B.  The  selection  for 
Group  B  is  Implemented  with  M13B,  MllB,  H12A  and  M12B. 

3.2.3  HI,  LO,  AND  THREShold  LEVEL  REFERENCES 

U1  through  U6  are  used  to  generate  and  store  the  HI,  LO,  and 
THREShold  references  used  in  groups  A  and  B.  Each  U1  is  a  full  four  quad¬ 
rant  multiplying  DAC  which  can  be  programmed  directly  from  the  ICA  bus. 

The  write  strobes  are  generated  in  the  ADCC  circuitry  described  in  Section 


3.3.  The  DAC  used  for  setting  the  digital  THREShold  level  uses  the  +10.00 
volt  reference  and  can  generate  a  THREShold  value  between  +  and  -  10.00 
volts.  The  DACs  which  hold  the  HI  and  LO  digital  output  levels  use  D/A 
reference  for  the  appropriate  group.  This  reference  Is  automatically  set 
to  +10.00  volts  for  single-ended  DC  output  configurations,  to  +5.00  volts 
for  differential  DC  output  configurations,  to  a  20  volt  p-p  zero  phase  slne- 
wave  for  single-ended  AC  output  configurations,  and  to  a  10  volt  p-p  zero 
phase  slnewave  for  differential  AC  output  configurations.  The  programmed 
count  In  each  of  the  DACs  allows  setting  the  HI  and  LO  references  to 
values  within  a  factor  of  +1  to  -1  of  these  values. 

3.3  ADDRESS  DECODING  AND  CONFIGURATION  CONTROL 

The  address  decoding  and  configuration  control  (ADCC)  function  Is 
performed  on  a  group  basis.  The  following  will  discuss  the  operation  of 
the  ADCC  section  for  Group  A  but  Is  applicable  to  the  Group  B  ADCC  section 
as  well.  The  block  diagram  for  the  ADCC  function  for  one  group  Is  shown 

In  Figure  36.  Appendix  b.  Section  3-C  contains  a  complete  schematic  and  parts 
list  for  the  ADCC  section. 

The  ADCC  function  Is  divided  Into  two  basic  operations:  the  decoding 
of  addresses  for  the  various  addressable  modules  In  the  group  and  the 
control  of  the  SIO  configuration. 

3.3.1  ADDRESS  DECODING 

The  addressable  modules  associated  with  each  group  are: 

1)  The  7  DACs  (A  for  analog  output  values  from  the  A  SIO 
channels  and  3  for  the  group  HI,  LO,  and  THREShold  values). 

2)  The  A  ADCs  (one  for  each  SIO  channel) . 


READ/ 

WRITE 


Diagram  of  the  Address  Decoding  Section 


3)  The  SIO  configuration  words  (2  addresses). 

4)  The  peripheral  interface  adaptor  (PIA)  (used  for  the  4 
parallel  digital  lines  of  the  group  and  to  provide  control 
lines  associated  with  the  serial  I/O  function,  requires  4 
addresses) . 

5)  The  synchronous  serial  data  adapter  (SSDA)  (used  for  the 
serial  I/O  function,  requires  2  addresses). 

The  above  units  require  a  total  of  15  unique  addresses  (note  that  the  4 
analog  output  DACs  and  the  4  analog  input  ADCs  use  the  same  4  addresses, 
an  LM  write  is  directed  to  the  appropriate  channel  DAC  and  an  LM  read  is 
directed  to  the  appropriate  channel  ADC).  The  address  map  for  each  group 
is  presented  in  Figure  37 . 

Ml  and  M7  perform  the  basic  address  decoding  function.  Ml  de¬ 
codes  relative  addresses  0  through  7  while  M7  decodes  relative  addresses 
8  through  14.  The  logic  of  M4A-B,  M5A-B,  M6A-E,  MlOA,  MIOD,  and  MllA-B 
serves  to  select  the  address  range  in  blocks  of  four  addresses  using  the 
address  lines  A2  through  A6  from  the  LM.  Note  that  the  only  change  re¬ 
quired  by  Group  B  is  the  inclusion  of  an  inverter  in  the  A4  address  line 
to  displace  the  addresses  by  16. 

Devices  are  read  by  the  LM  by  decoding  the  appropriate  address 
and  directing  the  read  strobe  to  the  appropriate  register.  The  delays 
caused  by  the  use  of  CMOS  logic  does  not  cause  problems  during  reads  since 
the  data  is  taken  from  the  ICA  by  the  LM  at  the  end  of  the  machine  cycle 
and  the  decoded  read  enable  occurs  near  the  beginning  of  the  cycle.  The 
setup  times  for  the  Interface  registers  are  met  by  using  a  1  MHz  clock  for 
the  LM  clock.  Devices  are  written  into  by  decoding  the  appropriate  address 
and  directing  the  write  strobe  to  the  selected  register.  The  delays  caused 
by  the  use  of  CMJS  logic  are  a  problem  since  the  data  is  to  be  taken  from 
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Figure  37  Memory  Map  of  ICA  Buffers 


the  data  bus  at  the  end  of  the  machine  cycle  and  the  edge  Is  delayed  rela¬ 
tive  to  the  data.  It  is  possible  for  the  data  on  the  LM  bus  to  change 
before  the  decoded  write  edge  propagates  to  the  selected  register.  This 
problem  is  circumvented  by  the  use  of  M29A  which  produces  the  write  edge 
(le,  terminates  the  write  strobe)  before  the  LM  cycle  is  finished. 

3.3.2  CONFIGURATION  CONTROL 

The  configuration  words  control  the  data  type  and  direction 
through  the  SIO  channels.  Figure  38  contains  a  description  of  the  bits 
used  in  each  of  the  two  configuration  words.  The  standard  configurations 
are  those  in  which  each  channel  of  the  SIO  performs  the  same  function. 

These  include  DC  and  AC  analog  input  and  output,  as  well  as  parallel 
digital  input  and  output.  The  choice  of  single-ended  versus  differential 
input  and  output  is  determined  by  the  programming  of  the  input  multiplexer 
address  lines  (INMUX0-A,  INMUXl-A  and  1NMUX2-A)  and  the  driver  enable  lines 
(DVRP  and  DVRN)  respectively. 

The  non-standard  SIO  functions  are  those  in  which  the  channels 
are  not  individually  programmed  the  same.  These  Include  the  serial  and 
synchro  input  and  output  modes.  These  special  configurations  are  control¬ 
led  by  M16  and  associated  logic. 

For  synchro  input,  output  SI  of  M16  is  high  which  results  in 
Inhibiting  the  drive  enable  lines  to  channels  1,  and  2  of  the  group. 

The  DVRP  and  DVRN  lines  can  be  applied  to  channel  3.  This  results  in  an 
AC  reference  being  made  available  through  channel  3  while  channels  0-2  are 
set  up  as  single-ended  input  channels  for  the  three  legs  of  a  synchro 
winding.  Note  that  channel  3  is  forced  to  a  differential  output  config¬ 
uration  Independently  of  the  state  of  DVRN.  This  allows  a  full  40  vp-p 
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CONFIGURATION  WORD  / 


1  AD 

ACDC 

DIV 

DVP 

DVN 

IM2 

IMl 

IMff 

AD  -  Selects  between  analog  (1)  and  digital  (fi). 

ACDC  -  Selects  between  AC(1)  and  DC(j(). 

DIV  -  Thevenin  source  on  (1)  or  off  (fj). 

OVP  -  Positive  voltage  driver  selected  (1)  or  deselected  (J6) 

DVN  -  Negative  voltage  driver  selected  (1)  or  deselected  (fi) 

IM0,  IMl,  -  Select  one  of  eight  Input  inodes.  Normal  operations 
IM2  utilize  single-ended  (3)  or  differential  (1)  mode. 

The  remaining  six  modes  are  used  for  test  purposes. 


CONFIGURATION  WORD  1 


DM3 

DM2 

DM1 

DM0 

X 

FLG 

OEN 

LF 

DM0-DM3  -  Select  one  of  the  special  configurations:  reset  (Jf) , 
test  (15) ,  serlal-out  (8) ,  serlal-ln  (4) ,  synchro-out 
(2),  and  synchro- in  (1). 


FLG  -  Selects  flag  (1)  or  refresh  (jfJ)  modes  during  serial 
Input. 


OEN  -  Voltage  drivers  on  (1)  or  off  00). 


LF  -  Selects  between  latched  (1)  and  followed  (f))  modes 
during  momentary  discrete  inputs. 


Figure  38  ICA  Configuration  Words 
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differential  output  from  channel  3  (If  DVRM  is  programmed  low  so  that  the 
reference  generation  section  maintains  a  full  20  vp-p  reference)  which 
makes  it  possible  to  drive  a  wide  range  of  available  synchros. 

For  synchro  output  the  S2  output  of  M16  will  be  high.  This  allows 
channel  3  to  be  configured  as  a  differential  channel  Independently  of  DVRN. 
Normal  synchro  output  would  use  channels  fi-Z  (single-ended)  to  drive  the 
three  legs  of  the  synchro  control  winding  (referenced  to  the  group  signal 
return)  and  use  channel  3  (differential)  to  drive  the  excitation  winding 
as  a  two  terminal  floating  load. 

For  serial  input  the  four  group  channels  are  used  as  follows: 

Channel  output  (request/lockout) 

Channel  1:  input  (flag/acknowledge) 

Channel  2:  output  (serial  clock) 

Channel  3:  input  (serial  data) 

This  configuration  is  forced  by  the  SA  output  from  M16  by  inhibiting  DVRN 
and  DVRF  for  channels  1  and  3. 

For  serial  output  the  four  group  channels  are  used  as  follows: 

Channel  0:  output  (request/lockout) 

Channel  1:  input  (flag/acknowledge) 

Channel  2:  output  (serial  clock) 

Channel  3:  output  (serial  data) 

This  configuration  is  forced  by  the  S8  output  from  M16  by  inhibiting  DVRN 
and  DVRP  for  channel  1. 
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3. A  SERIAL  I/O  DESIGN 


A  block  diagram  of  the  Serial  I/O  section  Is  shown  In  Figure  39. 

This  section  contains  the  logic  necessary  to  Implement  the  serial  I/O  func¬ 
tion  Including  parallel- to-serlal  and  serial- to-parallel  conversion,  FIFO 
buffering,  and  parity  checking.  Appendix  B,  Section  3-D  contains  a  complete 
schematic  and  parts  list  for  the  Serial  I/O  section. 

The  function  Is  performed  by  a  combination  of  discrete  logic  and  a 
single  LSI  programmable  Synchronous  Serial  Data  Adapter  (SSDA) ,  the  Motorola 
MC6852. 

The  MC6852  circuit  provides  the  functions  of  FIFO  buffering,  parallel- 
to-serlal  conversion,  serlal-to-parallel  conversion,  and  parity  checking. 

The  control  of  the  chip  Is  performed  by  external  logic  and  Internal  pro¬ 
gramming.  The  MC6852  contains  a  total  of  11  Internal  registers  Including 
a  3  byte  receive  FIFO,  a  3  byte  transmit  FIFO,  3  control  registers,  a 
status  register,  and  a  sync  code  register.  The  ICA  function  uses  all  of 
these  registers  with  the  exception  of  the  sync  code  register. 

The  following  discussion  will  reference  the  schematic  diagram  and  parts 

list  in  AppendlxB,  Section  3-D.  The  discussion  will  focus  on  the  SERIO  function 
for  Group  A  but  applies  as  well  to  the  SERIO  circuitry  In  Group  B. 

The  bit  rate  Is  selected  through  MIA  at  200  Kbps,  AO  Kbps,  20  Kbps, 
or  10  Kbps.  The  address  to  MIA  Is  programmed  via  the  CLKRTM  and  CLKRTIA 
lines  from  the  Group  A  ADCC  logic.  The  clock  rate  selection  Is  as  follows: 

Bit  Rate  CLKRT0A  CLKRTU 


r 


a 


The  number  of  bytes  of  data  to  be  transferred  Is  programmed  through 
the  WDCNTHIa  and  VJDCNTIA  lines.  These  lines  originate  in  the  Group  A  ADCC 
logic  and  are  applied  to  Mil  in  the  SERIO  section. 


Words 

WDCNT0A 

WDCNTIA 

1 

{) 

0 

2 

0 

1 

3 

1 

0 

The  SERIO  circuitry  can  operate  in  three  modes: 

1)  Output  Mode 

2)  Input,  Refresh  Mode 

3)  Input,  Flag  Mode  . 

These  modes  are  discussed  below. 

3.4.1  SERIAL  OUTPUT 

The  serial  I/O  circuitry  transmits  synchronous  serial  digital 
output  data  in  this  mode.  The  circuit  can  be  programmed  to  output  1,  2,  or 
3  bytes  of  information  during  a  transfer.  The  transfer  is  initiated  by 
the  LM  by  raising  the  STR/STP  line.  This  raises  the  REQ/LOK  line  to 

the  subsystem.  If  the  subsystem  is  able  to  accept  data  it  responds  by 
raising  the  FLAG/ACKnowledge  line  (DIGINl)  to  the  ICA.  This  initiates  the 
transmission  of  (N*9)  clock  pulses  to  the  subsystem  where  N  is  the  number 
of  words  programned  for  transmission.  The  last  bit  transferred  is  the 
parity  bit  for  the  last  word.  This  bit  is  checked  in  the  subsystem  at  the 
last  falling  edge  of  the  clock  and  the  parity  Information  is  used  by  the 
subsystem  to  set  the  final  state  of  the  FLAG/ACK  line.  The  LM  inspects 
the  End  of  Transmission  (EOT)  bit  to  determine  when  the  transfer  has  been 
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conq>leted.  The  LM  can  then  determine  the  state  of  the  FLAG/ACK  line  and 
finally  lower  the  REQ/LOK  line  to  the  subsystem.  If  an  error  occurred  the 
LM  can  take  appropriate  action.  The  serial  data  originates  at  pin  6  of  Ml 
and  is  buffered  through  the  appropriate  signal  I/O  channel  to  the  subsystem. 

3.4.2  SERIAL  INPUT-REFRESH  MODE 

The  refresh  mode  Is  one  of  two  Input  modes  provided  by  the  ICA. 
This  mode  allows  Input  to  take  place  under  control  of  the  ICA  through  re¬ 
quests  on  the  REQ/LOK  line.  The  data  Is  transferred  to  the  ICA  and  is 
received  by  the  FIFO  memory  in  the  MC6852.  The  process  is  similar  to  the 
output  mode  in  that  (N*9)  clock  pulses  are  provided  by  the  SERIO  circuit 
and  the  transmission  is  not  conqpleted  until  the  LM  has  determined  if  a 
parity  error  has  occurred.  Such  error  is  detected  by  the  LM  by  reading 
the  received  words  and  their  associated  parity  bits  out  of  the  FIFO  memory 
of  the  MC6852. 

3.4.3  SERIAL  INPUT- FLAG  MODE 

The  flag  mode  allows  the  Interfaced  subsystem  to  initiate  a  data 
transfer  to  the  ICA.  The  SERIO  circuitry  must  first  be  programmed  for  the 
expected  number  of  data  bytes  and  the  clock  rate  to  be  used  with  the  trans¬ 
fer.  The  transfer  process  is  Initiated  when  the  subsystem  raises  the 
FLAG/ACK  (DIGINl)  line  to  the  ICA.  This  action  causes  the  REQ/LOK  line  to 
the  subsystem  to  be  raised  in  response  and  allows  the  programmed  number  of 
clock  cycles  to  be  generated  and  sent  to  the  subsystem.  The  clock  is  frozen 
in  the  middle  of  the  last  programmed  cycle  so  that  the  LM  can  check  on  the 

parity  bit  state  for  each  of  the  received  words  in  the  FIFO  memory  of  the 

MC6852.  If  the  transmission  is  correct,  the  REQ/LOK  line  is  lowered  to 


the  subsystem  by  lowering  the  ERR  line  In  the  SERIO  circuit.  The  last 
clock  edge  Is  then  produced  through  the  CLKLOW  line  from  the  ICA  and  the 
subsystem  terminates  the  transmission  cycle.  If  an  error  occurs  during 
reception,  the  CLKLOW  line  Is  lowered  while  the  REQ/LOK  line  Is  still  high 
and  the  subsystem  will  be  ready  to  retransmit  the  message. 

The  parameters  and  control  bits  required  for  serial  transmission/re¬ 
ception  are  specified  In  the  serial  control  byte  of  the  ICA  configuration 
buffers.  This  byte  Is  set  up  In  the  data  register  of  a  Peripheral  Inter¬ 
face  Adapter  (PIA)  and  Is  Illustrated  In  detail  In  Figure  40. 


SERIAL  CONTROL 


SS  -  This  bit  controls  the  STR/STP  line  of  the  SERIO 

circuitry.  It  Is  used  to  Initiate  (1)  or  terminate 
{$)  the  serial  reception/ transmission. 


ERR  -  This  bit  controls  the  ERR  line  In  the  SERIO  circuitry. 


FLGR  -  This  bit  controls  the  serial  input  mode:  Flag  (1) 
or  refresh  (jd). 


WDCjl,-  These  bits  control  the  number  of  bytes  of  data  to  be 
WDCl  received/transmitted. 


CLK(<,-  These  bits  control  the  clock  rate  used  for  serial 
CLKl  reception /transmission. 


This  bit  Indicates  if  the  serial  transmission  is 
complete  (1)  or  not  (f>). 


Note:  The  CLKLOW  line  in  the  SERIO  circuitry  is  controlled  by 
the  CB2  peripheral  output  line  of  this  PIA.  CLKLOW  Is 
normally  low  and  is  set  high  to  provide  the  last  clock 
pulse,  after  which  it  Is  brought  low  again. 


Figure  40  Serial  Control  Byte 
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SECTION  4 


SUBSYSTEM  INFORMATION  CHANNEL 

The  SubsysCem  Information  Channel  (SIC)  Is  a  distributed  memory  system 
that  stores  Information  pertaining  to  devices  connected  to  a  computer  sys¬ 
tem.  The  Information  for  each  device  is  stored  In  an  electronic  nameplate 
physically  located  on  that  device.  Thus  It  becomes  simple  to  change  a 
system's  configuration,  since  at  initialization  the  processor  may  Interrogate 
the  SIC  to  determine  which  devices  are  present  and  establish  the  Interface 
requirement  for  each  device.  The  Information  stored  In  a  device's  nameplate 
Includes: 

•  Device  Identification, 

•  Interface  characteristics, 

•  Data  conversion  programs, 

•  calibration  programs, 

•  Diagnostic  programs, 

•  Failure/maintenance  records  written  when  In  previous  use. 

The  SIC  consists  of  two  major  types  of  components  (Figure  41  ) : 

•  Electronic  Nameplate  (NF):  The  information  storage  unit 
located  on  the  peripheral  device, 

•  Nameplate  Interface  Controller  (NIC):  ao  interface  module 
which  resides  in  the  processor  chassis  and  enables  com¬ 
munication  between  the  processor  and  nameplates. 

Many  subsystems  consist  of  several  modules,  each  with  specific  Inter¬ 
face  requirements.  In  this  case  each  module  may  be  equipped  with  an 
electronic  nameplate  containing  information  specific  to  that  module.  All 


Figure  41  The  Subsystem  Information  Channel 


lectronlc  nameplates  within  a  subsystem  are  "daisy-chained"  along  an  SIC 
bus. 

The  Subsystem  Information  Channel  is  viewed  as  a  distributed  memory  by 
programs  running  in  the  processor.  Programs  may  "read"  the  nameplate's 
memory  through  the  SIC  by  using  SIC  commands. 

The  following  section  gives  an  explanation  of  how  to  use  the  SIC  and 
later  sections  discuss  the  design  of  the  parts  of  the  Subsystem  Information 
Channel. 

4.1  USE  OF  A  SUBSYSTEM  INFORMATION  CHANNEL 

This  section  describes  the  control  and  comnunicatlon  protocol  utilized 
by  the  subsystem  information  channel  to  access  any  of  its  electronic  name¬ 
plates.  The  communication  protocol  and  its  use  are  presented  first.  Use 
of  the  control,  status  and  data  registers  of  the  nameplate  interface 
controller  is  presented  next.  A  structure  for  storing  the  information  re¬ 
siding  in  an  electronic  nameplate  is  presented  at  the  end  of  this  section. 

4.1.1  ELECTRONIC  NAMEPLATE  COMMANDS 

Control  of  a  nameplate  by  a  processor  is  accomplished  through  the 
use  of  electronic  nameplate  commands.  The  nameplate  receiving  the  command 
sends  a  specific  response  to  the  processor  acknowledging  that  the  required 
action  has  been  performed.  The  nameplate  commands  may  be  grouped  into  four 
functional  categories: 

s  Nameplate  selection  commands, 
s  Read  memory  coamands, 
e  Vfrite  memory  comautnds, 

•  Nameplate  diagnostic  coBaaands. 
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4. 1.1.1  Nameplate  Selection  Coamands 

The  nameplate  selection  conmands  are  used  to  establish  processor 
communication  with  one  of  several  nameplates.  The  two  commands  "select 
level  0  NP"  and  "select  next  NP"  allow  a  program  to  sequentially  select 
nameplates  on  the  SIC  bus.  This  procedure  starts  with  the  nameplate  near¬ 
est  to  the  processor  which,  by  position.  Is  assigned  level  fi.  Once  a 
nameplate  Is  selected.  It  may  be  assigned  an  eight  bit  address  which  may 
be  used  for  subsequent  random  nameplate  selection.  This  Is  accomplished  by 
the  commands  "assign  NP  address"  and  "select  NP  by  address".  During 
Initialization  the  sequential  selection  mode  Is  used  to  assign  nameplate 
addresses.  Thereafter  a  particular  nameplate  Is  selected  usually  by  Its 
address . 

The  Identity  of  Che  nameplate  selected  can  be  determined  at  any 
time  through  the  use  of  the  command  "read  selected  NP's  address".  Absence 
of  a  response  to  this  command  Indicates  that  no  nameplate  Is  selected. 

Each  nameplate  sets  Its  address  to  an  Invalid  address  (-1)  whenever  It  is 
reset.  A  nameplate  can  be  reset  by  the  processor  via  the  nameplate  Inter¬ 
face  controller  or  whenever  the  nameplate's  power  or  clock  Is  absent. 

Only  one  nameplate  can  be  selected  at  a  time.  If  a  nameplate  Is 
selected  and  a  "select  level  0  NP"  consoand  Is  Issued,  the  selected  nameplate 
will  deselect  and  the  level  0  nameplate  will  become  selected  and  respond 
to  the  command.  If  a  nameplate  Is  selected  and  a  "select  next  NP"  Is 
Issued,  the  presently  selected  nameplate  deselects,  and  the  next  nameplate 
on  the  SIC  bus  (further  from  the  processor)  becomes  selected  and  responds 
to  the  command.  Note  that  the  "select  next  NP"  command  has  no  effect  If 
no  nameplate  Is  selected.  If  a  nameplate  Is  selected  and  It  Is  desired  to 
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select  another  nameplate  using  the  "select  NP  by  address"  comnand,  the  first 
naaieplate  must  be  deselected  using  the  connnand,  "deselect  HP",  and  then  the 
desired  nameplate  may  be  selected. 

A  bit  in  the  nameplate  status  byte  (the  first  byte  of  every  re¬ 
sponse)  indicates  if  the  responding  nameplate  is  the  last  nameplate  on  the 
SIC  bus  (l.e.  the  farthest  from  the  processor).  If  the  last  nameplate  is 
selected  and  a  "select  next  NP"  command  is  issued,  the  last  nameplate  will 
deselect  and  no  nameplate  will  be  selected  thus  no  response  will  be  issued. 

4. 1.1. 2  Read  Memory  Command 

Once  an  electronic  nameplate  is  selected,  its  memory  may  be  read. 
The  nameplate's  memory  consists  of  read  only  memory  used  for  storage  of 
subsystem  Interfacing  information  and  read/write  memory  used  for  storage 
of  subsystem  performance  records.  The  command  "read  selected  NP's  memory" 
allows  the  processor  to  transfer  up  to  256  bytes  of  data  from  the  nameplate's 
read  only  or  read/write  memory.  This  is  accomplished  by  sending  with  the 
command  the  starting  address  and  number  of  bytes  to  be  transferred.  If 
more  than  256  bytes  are  required,  additional  read  memory  conmands  may  be 
Issued  each  with  a  new  starting  address.  Only  if  the  starting  address  and 
ending  address  (l.e.  starting  address  +  number  of  bytes  requested)  are 
within  the  nameplate's  memory  boundaries  will  the  data  transfer  request  be 
honored.  Otherwise  the  nameplate's  response  will  indicate  an  invalid 
address  status. 

4.1.1. 3  Write  Memory  Commands 

Information  may  be  stored  in  a  nameplate's  read/write  memory 
through  the  use  of  the  "write  NP  memory"  connand.  For  the  sake  of  security. 


a  write  command  to  a  nameplate  will  not  be  honored  unless  it  Is  preceeded 
by  the  "NP  write  enable"  command. 

Data  written  Into  a  nameplate's  read/write  memory  is  stored  In 
records.  Each  record  consists  of  a  16  byte  block.  The  starting  address 
of  each  record,  sent  with  the  write  command,  must  start  on  a  16  byte 
boundary  (l.e.  the  last  hexadecimal  digit  of  the  address  must  be  zero). 

The  last  two  bytes  of  each  record  are  used  to  store  a  record  checksum  and 
a  record  terminator.  These  bytes  are  Inserted  by  the  nameplate  logic  when 
the  record  Is  written.  Thus  the  maximum  number  of  data  bytes  that  can  be 
written  Into  a  record  Is  fourteen.  The  most  significant  bit  of  the  first 
byte  In  each  record  Is  utilized  as  a  record  validity  Indicator.  Modifying 
this  bit  Is  the  last  operation  performed  In  response  to  a  write  conmand. 
This  bit  when  set  to  zero  Indicates  that  the  record  Is  properly  written. 

Each  nameplate  may  contain  sixteen  such  written  records  at  any 
time.  These  records  are  written  In  non-volatile  memory  (l.e.  the  nameplate 
may  be  powered  down  and  the  written  information  will  be  retained) .  The 
starting  address  of  the  first  unwritten  record  space  (l.e.  the  unused 
record  space  with  the  lowest  address)  may  be  obtained  by  using  the  command 
"next  available  record  address".  An  address  of  zero  returned  In  response 
to  this  command  Indicates  that  the  nameplate's  read/write  memory  Is  full. 

A  nameplate's  read/write  memory  can  be  erased  through  the  use 
of  the  "erase  read/write  memory"  command.  The  erase  command  Is  in  the 
write  category  of  conmands  and  therefore  must  be  preceeded  by  the  "NP  write 
enable"  conmand.  The  present  Implementation  of  the  electronic  nameplate 
does  not  support  the  actual  erasure  of  memory.  Receipt  of  the  erase  com¬ 
mand  Is  acknowledged  by  lighting  the  nameplate's  erase  Indicator.  The 


nameplate's  read/write  memory  must  be  removed  from  the  nameplate  board  and 
exposed  to  ultra-violet  light  for  fifteen  minutes  in  order  to  be  erased. 

Execution  of  the  write  (or  erase)  command  requires  approximately 
one  second.  The  nameplate  will  acknowledge  receipt  of  these  commands 
immediately  and  will  proceed  to  execute  the  write  (or  erase)  action.  Dur¬ 
ing  this  time  only  the  select,  deselect  commands  and  the  "read  selected  NF 
address"  command  will  be  accepted  and  executed.  Other  commands  will  be 
rejected  and  the  response  will  Indicate  "NP  busy".  However,  if  it  is  de¬ 
sired  to  terminate  a  write  (or  erase)  prior  to  Its  completion,  the  command 
"abort  selected  NP"  may  be  used. 

The  nameplate  should  be  disabled  from  writing  (or  erasing)  as 
soon  as  the  desired  write  (or  erase)  has  been  completed.  This  action  will 
avoid  accidental  modification  of  the  read/write  memory.  The  write  disable 
Is  accomplished  through  the  use  of  "NP  write  enable"  command  with  the 
enable/disable  flag  not  equal  to  one. 

4. 1.1. 4  NP  Diagnostic  Commands 

The  last  group  of  commands  cause  the  nameplate  to  run  a  self-test 
program.  When  the  command  "run  NP  diagnostic"  Is  Issued,  the  selected 
nameplate  will  respond  Immediately  and  start  execution  of  Its  diagnostic 
routine.  The  diagnostic  routine  requires  approximately  1/4  second  of  exe¬ 
cution.  During  diagnostic  execution  only  the  select,  deselect  commands 
and  the  "read  selected  NF's  address"  command  will  be  accepted.  Other 
commands  will  be  rejected  with  a  status  of  "NP  busy".  Execution  of  the 
diagnostic  routine  may  be  prematurely  terminated  with  the  "abort  selected 
NP"  command.  When  the  diagnostic  is  completed,  the  results  may  be  read  by 
issuing  the  command  "read  NP  diagnostic  results".  Figure  42  Illustrates 


First  Result  Byte 


b7  b6  bS  b4 
DCG  I  ROME  I  ji  |rECE 


b2  bl  b0 
RAME  (time  I  0 


DGC:  Diagnostic  completed 

ROME:  ROM  data  errors 

RECE;  Read/Write  records  in  error 
RAME :  RAM  errors 

TIME :  Timer  errors 


Second  Result  Byte 


R0M4: 

ROMS: 

ROM2: 

ROMl: 

FREE  REC: 


ROM  number  4,  address  (58|Jf-5FFF)i6,  data  errors 
ROM  number  3,  address  (5W0-57FF)  15,  data  errors 
ROM  number  2,  address  (48j?0-4FFF)  16,  data  errors 
ROM  number  1,  address  (4j000-47FF)i6,  data  errors 
Number  of  read/vnrite  records  still  available 


NOTE:  A  one  in  the  associated  bit  position  indicates  the 
condition  is  true. 


Figure  42  NP  Diagnostic  Result  Data  Bytes 


the  format  In  which  the  results  are  returned. 


4. 1.1. 5  Command  and  Response  Structure 

The  structure  of  all  valid  nameplate  commands  is  presented  in 
Table  16.  The  same  table  also  identifies  the  format  of  the  response  to 
each  command.  Commands  and  responses  have  different  numbers  of  bytes 
depending  on  the  amount  of  information  required  by  the  action  requested. 
Figures  43a  and  43b  show  the  message  structure  of  various  commands  and 
associated  responses  in  terms  of  their  byte  contents.  Note  that  the  name¬ 
plate  status  is  always  the  first  byte  of  the  response.  When  an  error  is 
encountered  in  the  execution  of  a  comnand  the  second  (and  last)  data  byte 
of  the  response  will  diagnose  the  cause  of  the  error.  The  structure  of 
the  status  bytes  is  presented  in  Figures  44a  and  44b. 

4.1.2  NAMEPLATE  INTERFACE  CONTROLLER  REGISTERS 

The  nameplate  Interface  controller  is  the  controller  circuit, 
residing  in  the  processor  chassis,  through  which  communication  with  name¬ 
plates  takes  place.  As  viewed  by  the  processor,  the  nameplate  Interface 
controller  appears  as  a  set  of  memory  mapped  control,  status  and  data 
registers. 

4. 1.2.1  SIC  Status  and  Control  Registers 

One  of  these  registers,  the  SIC  status  register,  reflects  the 
status  of  the  subsystem  information  channel  as  shown  in  Figure  45a  .  Bits 
7,  4  and  3  reflect  the  signal  level  of  specific  SIC  hardware  control  lines 
Bits  2,  1  and  0  are  outputs  of  the  SIC  clock  divider  circuit.  Consecutive 
reads  of  the  status  register  should  yield  a  changed  value  for  bits  2,  1 
and  0  if  the  SIC  clock  is  functioning  correctly.  This  value  changes 
approximately  every  13.1  microseconds. 
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Table  16 


Figure  43b  SIC  Command  Response  Byte  Structure 


CER:  Command  error 
NPB:  NP  is  busy 

LNP:  This  NP  is  the  last  NP  on  the  SIC  bus 

WRE:  Error  occurred  on  last  write 

DLA:  Deselect  acknowledge 

WED:  Write  enabled/disabled  flag  Cenabled=l) 

DTI,  DT0:  Indicated  type  of  data  in  response  as  follows: 


CER  DTI  UTjS 

0/9  0 

0  Jlf  1 

0  10 

0  1  1 

1  X  X 


Response  Data 

Nameplate  Address 

Diagnostic  Results 

Memory  Address  Only 

Memory  Address  and  Memory  Data 

Error  Diagnostic  Byte 


NOTE:  A  one  in  the  associated  bit  position  indicates  condition 
is  true. 


Figure  44a  Nameplate  Status  Byte 
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b7 

b6 

bS 

b4 

b3 

b2 

bl 

hd 

1  INC  1 

1  INA  1 

flNS  1 

n 

n 

wm 

INC:  Invalid  conunand 

INA:  Invalid  memory  address  (either  starting  or  ending  address) 
INW:  Invalid  vrrite  (erase)  request,  write  not  enabled 
CER:  Communication  error 

INS;  Another  NP  requested  while  this  NP  is  still  selected 


NOTE:  A  one  in  the  associated  bit  position  indicates  the 
condition  is  true 


Figure  4Ab  Error  Diagnostic  Byte 
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b4 


b3 

R/C 


bl 


Address : 
X  X  X  2 


b7  b6  bS 


1  PWR 

m 

NPR 

b2 

CL2 


CLl 


PWR:  SIC  power  status  {1=SIC  power  not  present) 

NPR:  NP  reset  line  level 

R/C:  RESP/CMD  line  level 

CL2,  CLl,  CL0:  SIC  clock  status  bits 


NOTE:  A  one  in  the  associated  bit  position  indicates  the 
condition  is  true 

Figure  ^5a  SIC  Status  Register 


b7 

b6 

b5 

b4 

b3 

b2 

bl 

1  PWO 

s 

un 

n~ 

In^ 

rn 

CD 

Address : 
X  X  X  3 


PWO:  Power  outage  (or  SIC  disconnection)  since  last  read  of  SIC 
status  register 
NPR:  NP  reset  control 

PIE:  Power  outage  (or  SIC  disconnection)  interrupt  enable 


NOTE:  A  one  in  the  associated  bit  position  indicates  the 
condition  is  true 


Figure  45b  SIC  Control  Register 


Figure  45b  Illustrates  the  SIC  control  register.  This  register 
Is  used  primarily  for  Initializing  the  SIC  status  register  and  for  resetting 
all  nameplates.  The  simultaneous  reset  of  all  nameplates  Is  accomplished 
by  setting  (to  one)  bit  3  (NPR)  of  the  control  register.  As  long  as  the 
NPR  bli.  Is  set,  all  nameplates  will  remain  In  the  reset  state.  To  enable 
the  nameplates  after  a  reset  Is  performed,  the  NPR  bit  should  be  reset  (to 
zero).  The  processor  should  wait  approximately  40  milliseconds  after  re¬ 
moving  the  reset  signal  before  attempting  to  access  a  nameplate.  This  delay 
is  required  to  allow  the  nameplates  to  Initialize. 

The  PWO  bit  will  be  set  in  the  SIC  control  register  whenever  the 
subsystem  Information  channel  loses  power  as  a  result  of  power  supply 
malfunctions  or  breaks  In  the  SIC  bus  (e.g.  on  reconfiguration).  The  PWO 
bit  will  stay  set  even  if  power  returns  to  the  SIC  bus.  This  bit  will  be 
cleared  when  the  SIC  status  register  Is  read.  The  PWR  bit  (bit  7)  of  the 
SIC  status  register  Indicates  the  status  of  the  SIC  power  at  the  time  of 
the  read.  Thus  If  power  goes  down  and  returns  between  readings  of  the  SIC 
status  register,  the  PWR  bit  of  the  SIC  status  register  will  be  zero  In 
both  readings.  However  the  PWO  bit  of  the  SIC  control  register  will  be  set 
to  one  Indicating  that  a  power  loss  has  occurred.  The  SIC  control  register 
should  always  be  read  before  reading  the  SIC  status  register  since  reading 
the  SIC  status  register  clears  the  PWO  bit  of  the  SIC  control  register. 

An  Interrupt  to  the  processor  may  be  generated  when  the  PWO  bit  Is  set  to 
one.  The  PIE  bit  (bit  d)  of  the  control  register  controls  the  enabling 
and  disabling  of  this  Interrupt. 

The  SIC  status  and  control  registers  should  be  Initialized  In  the 
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following  manner: 


1)  write  (3A)^g  to  the  SIC  control  register, 
ii)  write  the  SIC  status  register, 

lii)  write  to  the  SIC  control  register, 

Iv)  read  the  SIC  status  register. 

After  this  procedure  is  performed  the  SIC  status  and  control  registers'  bit 
functions  are  as  Indicated  in  Figures  45a  and  b. 

Additional  Information  on  the  functions  of  each  bit  In  the  SIC 
control  and  status  registers  is  presented  In  the  nameplate  Interface  con¬ 
troller  hardware  schematics  (Appendix B,  Section  4-A  and  the  data  sheets  on  the 
Motorola  ^£36821  peripheral  Interface  adapter. 

4, 1.2. 2  SIC  Communication  Registers 

The  sending  commands  and  receiving  responses  from  nameplates  is 
accomplished  with  the  aid  of  two  registers:  the  SIC  communication  control/ 
status  register  and  the  SIC  communication  data  register.  Figures  46a  and 
46b  depict  the  format  of  these  registers. 

The  SIC  communication  control/ status  accepts  controls  when  written 
and  provides  communication  status  when  read.  The  R/C  bit  (bit  6}  of  the 
SIC  communication  control  register  controls  the  direction  of  the  data  on 
the  SIC  serial  data  bus.  The  SIC  is  enabled  to  send  a  command  to  the  name¬ 
plates  by  writing  a  zero  into  the  R/C  bit.  The  nameplates  are  enabled  to 
respond  to  a  command  when  the  processor  writes  a  one  to  this  control  bit. 

Two  other  important  bits,  RIE  and  TIE,  are  used  to  enable  receiver  buffer 
full  and  transmitter  buffer  empty  interrupts  respectively.  To  initialize 
the  SIC  communications,  the  value  (/)3).,  should  be  written  into  the  com- 
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fflunlcatlon  control  register. 
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Control  Register 


b7 

b6 

bS 

b4 

b3 

b2 

bl 

^  bj^ 

Liil 

3 

TIE  1 

1  1 

□H 

E 

E 

E] 

Address : 

X  X  X  4 
(write  only) 


RIE:  Receiver  data  available  interrupt  enable 
R/C:  RESP/CMD  enable  control  (laRESP) 

TIE:  Transmitter  empty  interrupt  enable 


NOTE:  To  reset  communications,  write:  /(s. 


Status  Register 


b7 

b6 

bS 

b4 

b3 

b2 

bi 

bj!l 

LiiiJ 

0 

1  OVR  1 

FE 

|r/c 

[Z 

1  TXE 

RDA 

Address : 

X  X  X  4 
(read  only) 


IRQ:  Interrupt  present 
OVR:  Receiver  data  overrun  error 
FE:  Receiver  data  framing  error 

R/C:  RESP/CMD  enable  status  (1®RESP) 
TXE:  Transmitter  data  register  empty 
RDA:  Receiver  data  available 


NOTE:  A  one  in  the  associated  bit  position  indicates  the 
condition  is  true 


Figure  46a  SIC  Communication  Control/Status  Register 
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Receive  Register 


b6  b5  b4  b3  b2  bl  b/l 
DATA  BYTE 


Transmit  Register 


b7  b6  bS  b4  b5  b2  bl  h0 
DATA  BYTE 


rE: 


Data  is  in  8-bit  bytes,  no  parity. 


Figure  46b  SIC  Communication  Data  Register 


Address : 

X  X  X  5 
(read  only) 


Address : 

X  X  X  5 
(write  only) 


Reading  the  SIC  communication  control/status  register  will  yield 
the  SIC  communication  status  as  Indicated  in  Figure  46a  . 

Command  or  data  to  be  transmitted  to  a  nameplate  must  be  written 
Into  the  SIC  communication  data  register  (Figures  46b  ) .  Transmission  to 
the  nameplates  will  only  take  place  If  the  R/C  control  bit  Is  reset  (l.e., 
command  enabled).  The  response  from  a  nameplate  Is  read  from  the  SIC 
communication  data  register  (Figure  46b).  No  response  will  be  received 
unless  the  R/C  control  bit  Is  set  to  one  (l.e.,  response  enabled).  The 
processor  should  delay  approximately  2.1  milliseconds  after  transmitting 
the  last  byte  of  a  command  before  enabling  the  response  (l.e.  setting  the 
R/C  control  bit  to  one).  This  action  will  assure  that  all  bytes  sent  are 
received  by  the  nameplates. 

A  more  detailed  explanation  of  the  functions  of  each  bit  In  the 
SIC  communication  registers  Is  provided  in  the  nameplate  interface  control¬ 
ler  hardware  schematics  (Appendix  B,  Section  4-A)  and  the  data  sheets  on  the 
Motorola  MC6850  asynchronous  Interface  adapter. 

4.1.3  NAMEPLATE'S  DATA  STRUCTURE 

The  electronic  nameplate  can  be  viewed  as  a  component  of  a  dis¬ 
tributed  memory  system.  The  distributed  memory  (l.e.,  the  nameplate's 
memory)  Is  used  to  store  Information  related  to  the  subsystem  on  which  the 
memory  Is  attached.  The  design  of  the  electronic  nameplate  places  no 
restriction  on  the  data  structure  of  Information  stored  In  the  nameplate's 
read  only  memory.  The  nameplate's  read/write  memory  Is  used  for  storing 
subsystem  performance  Information.  The  read/write  memory  Is  organized  In 
terms  of  16  byte  records.  Fourteen  of  the  bytes  In  a  record  may  be  used 
for  data  storage  and  are  not  restricted  In  format.  A  restriction  Is  placed 


on  the  most  significant  bit  of  the  first  byte  of  each  record.  This  bit  will 
be  set  to  zero  by  the  nameplate  logic  if  the  record  is  written  correctly. 

The  nameplate's  memory  format  allows  a  variety  of  data  structures 
to  be  used  for  storage  of  subsystem  Information.  In  order  to  facilitate 
Information  retrieval,  the  organization  of  subsystem  data  within  a  nameplate 
should  have  a  well  defined  structure.  The  rest  of  this  section  will  dis¬ 
cuss  the  nameplate's  subsystem  Information  storage  structure  for  implemen¬ 
tation  of  a  subsystem  information  channel. 

Each  nameplate  will  have  a  directory  in  read  only  memory  identify¬ 
ing  all  Information  structures  present  in  the  nameplate.  The  format  of  this 
directory  is  Illustrated  in  Figure  47.  The  directory  of  any  nameplate 
starts  at  a  fixed  (known)  memory  address.  The  different  information  modules 
which  a  nameplate  may  have  in  read  only  memory  Include: 

•  Subsystem  identification, 

•  Subsystem  interfacing  characteristics, 

•  Subsystem  I/O  routines, 

•  Subsystem  diagnostic/calibration  routine. 

The  presence  of  each  of  the  above  modules  in  a  nameplate's  memory  will  be 
identified  with  a  corresponding  entry  in  the  directory. 

The  initial  segment  of  each  information  module  contains  a  header. 
This  header  provides  a  physical  description  of  the  module.  The  information 
in  a  header  includes: 

a  Identification  of  the  module, 

•  Size  of  the  module, 

•  Address  of  the  first  executable  instruction, 

e  Checksum  for  the  module. 


The  last  entry  In  a  naoeplate's  directory  contains  the  starting 
address  and  size  of  the  read/write  memory  area.  The  format  of  a  subsystem 
performance  record  written  In  the  read/write  area  Is  shown  In  Figure  48. 

The  first  byte  Is  an  Identifier  for  the  type  of  data  In  the  record.  Typical 
record  types  Include: 

e  Subsystem  failure  reports, 
e  Subsystem  repair  reports, 

•  Subsystem  calibration  results, 
e  Subsystem  diagnostic  results. 

The  eight  unspecified  bytes  In  a  record  may  be  used  to  store  information 
relevant  to  the  action  causing  the  recording  (i.e.  record  type). 

4.2  ELECTRONIC  NAMEPLATE  DESIGN 


4.2.1  HARDWARE  DESIGN 

The  design  of  electronic  nameplates  for  the  subsystem  information 
channel  is  based  on  a  Motorola  ^6801L1  processor.  The  electrical  specifi¬ 
cations  for  the  nameplate  are  presented  In  Table  17.  One  should  observe 
that  power  for  all  nameplates  is  supplied  by  the  SIC  bus.  Therefore  the 
SIC  power  supplies  must  be  sized  to  handle  the  maximum  number  of  nameplates 
for  a  given  application. 

Theory  of  Operation 

A  description  of  the  nameplate's  operation  can  be  made  in  terms 
of  the  block  diagram  shown  In  Figure  49.  The  detailed  schematic  drawings 
for  the  nameplate  are  presented  In  Appendix  B,  Section  4-B. 

The  majority  of  the  logic  functions  required  from  the  electronic 
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Table  17 


ELECTRONIC  NAMEPLATE  SPECIFICATIONS 


CHARACTERISTIC 


SPECIFICATIONS 


Power  Requirements 


+5Vdc  ±5%  @  1.2  Amps 
+25Vdc  ±S%  @  50ma 


Input  Signals 
Output  Signals 
Operating  Frequency 
Operating  Temperature 
External  Interfaces 


TTL  voltage  compatible 
TTL  voltage  compatible 
614.4  K  Hz 
0  to  70»C 
SIC  Bus 


nameplate  are  performed  by  a  Motorola  MC6801L1  processor.  This  processor 
Is  configured  In  Its  expanded  multiplexed  mode  of  operation  and  Includes 
the  following  operational  elements: 

•  6800+  CPU:  Motorola  6800  processor  with  an  enhanced 
Instruction  set, 

•  128  bytes  of  RAM  memory, 

•  serial  transmitter/receiver  communication  device, 

•  free  running  timer  which  can  output  software  controlled 
pulses  and  also  measure  times  between  input  transitions, 

•  8  bits  of  digital  I/O. 

Detailed  specifications  for  the  processor  are  provided  by  Motorola  documen¬ 
tation  on  the  MC6801L1. 

All  external  signals  required  by  the  nameplate  are  provided  by 
the  SIC  bus.  These  signals  are  shown  on  the  left  side  of  Figure  49.  The 
function  of  each  major  component  identified  in  the  nameplate  block  diagram 
will  be  described  in  the  remainder  of  this  section. 

Reset  Circuit 

When  power  is  turned  on  or  the  SIC  clock  recovers  from  an  inter¬ 
ruption,  this  circuit  causes  the  nameplate  logic  to  reset.  The  reset 
signal  goes  false  approximately  30  milliseconds  after  the  power  and  clock 
are  both  present. 

Serial  Data  Buffers 

This  logic  circuit  uses  the  RESF/CMD  SIC  bus  signal  to  control 
the  direction  of  data  flow  to  or  from  the  SIC  simplex  serial  data  line. 
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Command  Detection 


This  circuit  detects  when  the  RESP/CMD  signal  goes  low  Indicating 
the  start  of  a  new  command  from  the  system  processor.  This  negative  going 
edge  Is  latched, causing  an  Interrupt  In  the  6801  CPU.  The  6801  CPU  clears 
the  Interrupt  through  one  of  Its  8  digital  I/O  lines. 

Address  Latch  and  Decoding 

The  expanded  multiplexed  mode  of  operation  (mode  1)  of  the  6801 
multiplexes  the  lower  8  bits  of  address  with  the  corresponding  data  bits. 
Therefore  the  8  lower  order  address  bits  must  he  demultiplexed  with  an  ex¬ 
ternal  latch.  Address  lines  A15  through  A5  are  then  applied  to  a  decoding 
ROM  that  generates  the  chip  select  signals  for  various  nameplate  memory 
components  and  control  devices. 

Write/Erase  Control 

This  logic  provides  the  capability  to  write  256  bytes  of  data  on 
an  EPROM.  This  logic  contains  an  8  bit  latch  for  holding  the  address  and 
an  8  bit  latch  for  holding  the  data  to  be  written.  It  also  provides  the 
write  control  required  to  trl-state  the  EPROM  from  the  nameplate's  data  and 
address  buses  during  programming.  The  write  control  also  gates  the  MC6801 
timer's  50  millisecond  pulse  and  switches  the  +25  volt  power  as  required  to 
program  the  EPROM. 

The  EPROM  Implementation  of  the  read/write  memory  does  not  permit 
electrical  erasure.  The  erase  control  utilizes  the  6801  timer  to  generate 
a  one  second  erase  pulse.  This  pulse,  in  the  present  Implementation,  lights 


an  LED  which  Is  used  for  command  verification. 


Priority  Logic 

The  priority  logic  "ANDs"  the  PRIORITY  IN  signal  froa  the  SIC  bus 
with  the  signal  THNPSELN  (this  nameplate  Is  selected),  an  output  signal 
from  the  6801  digital  1/0  port,  to  form  the  SIC  bus  signal  PRIORITY  OUTN. 

The  SIC  bus  connects  to  the  nameplate  In  such  a  way  that  the  PRIORITY  OUTN 
signal  of  one  nameplate  becomes  the  PRIORITY  IN  signal  of  the  next  nameplate 
farther  away  from  the  system  processor.  If  a  nameplate  Is  selected.  Its 
THNPSELN  signal  Is  low.  Thus  the  PRIORITY  IN  signals  of  all  nameplates 
farther  away  from  the  processor  are  low. 

A  line  of  the  6801* s  I/O  port  Is  used  to  allow  the  nameplate's 
software  to  test  the  value  of  Its  PRIORITY  IN  signal.  When  a  nameplate's 
PRIORITY  IN  signal  Is  low.  It  indicates  that  some  nameplate  closer  to  the 
system  processor  (l.e.  a  higher  priority  nameplate)  is  selected.  The  name¬ 
plate  sensing  a  low  PRIORITY  IN  has  lower  priority  and  therefore  must 
function  accordingly. 

Another  line  of  the  6801' s  I/O  port,  the  LAST  NP  signal,  is 
checked  by  the  nameplate's  software  to  determine  If  It  Is  the  last  name¬ 
plate  on  the  SIC  bus  (l.e.  the  farthest  from  the  system  processor).  The 
nameplate's  PRIORITY  OUTN  signal  passes  through  a  current  limiting  resistor 
before  It  Is  applied  to  the  SIC  bus.  The  LAST  NF  signal  is  connected  to 
the  PRIORITY  OUTN  signal  on  the  SIC  bus  side  of  this  resistor.  For  all 
nameplates  that  are  not  the  last  on  the  bus,  the  signal  LAST  NP  follows 
the  signal  PRIORITY  OUTN.  The  SIC  bus  terminator,  placed  after  the  last 
nameplate  on  the  SIC  bus.  Jumpers  the  PRIORITY  OUTN  signal  to  the  SIC  +5 
volt  power  line.  Thus  In  the  last  nameplate,  the  signal  LAST  NP  will  be 
high  even  when  the  Inputs  to  the  priority  logic  circuit  (THNPSELN  and 
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PRIORITY  IN)  dictate  the  signal  should  be  low.  The  nameplate's  software, 
by  monitoring  the  Inputs  to  the  priority  logic  and  this  LAST  NP  signal,  can 
determine  If  It  Is  the  last  nameplate  on  the  SIC  bus. 

Status  Display 

These  buffers  are  used  to  drive  LED  displays  that  Indicate  the 
nameplate  status.  Some  of  the  displays  Indicate  the  Internal  status  of  the 
6801  and  Its  software.  The  remaining  LEDs  are  driven  by  Important  hardware 
signals.  Table  18  lists  the  status  Identified  through  LED  displays. 

SIC  Bus 

The  SIC  bus  provides  the  medium  for  a  processor  to  communicate 
with  one  or  more  nameplates.  Control  of  the  bus  by  the  processor  Is 
achieved  with  the  nameplate  interface  controller  residing  in  the  processor. 
The  SIC  bus  also  supplies  power  and  the  clock  for  the  nameplates.  When 
multiple  nameplates  are  used  they  are  "daisy  chained"  along  the  SIC  bus 
as  Illustrated  In  Figure  50. 

The  SIC  bus  must  be  properly  terminated  at  the  last  nameplate. 

This  termination  consists  of  two  Jumpers  connecting  the  bus  signals 
BPRIORITY  and  BDISCONN  to  the  +5  volt  power  line.  The  BPRIORITY  jumper  is 
used  to  indicate  this  nameplate  Is  the  last  one  on  the  bus.  The  BDISCONN 
jumper  causes  the  corresponding  bus  line  to  be  held  high  at  the  nameplate 
Interface  controller.  This  will  remain  true  until  the  SIC  "daisy  chain" 

Is  opened.  The  nameplate  Interface  controller  uses  this  signal  to  detect 
when  a  nameplate  (and  corresponding  subsystem)  has  been  replaced  or  recon¬ 
figured.  Table  19  Identifies  the  signals  comprising  the  SIC  bus.  Appendix 
B,  Section  4-B  contains  detailed  Information  on  the  cable  implementation. 
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Table  18 


NP  STATUS  DISPLAY 


LED  NUMBER* 

STATUS  DISPLAYED 

1 

NP  is  busy 

2 

This  NP  is  selected 

3 

SIC  RESP/CMD  bus  line  level  (CMD=ON) 

4 

SIC  SERIAL  DATA  bus  line  level 

5 

EPROM  write  strobe 

6 

EPROM  simulated  erase  strobe 

7 

SIC  PRIORITY  IN  bus  line  level  (High=on) 

8 

NP  Diagnostic  is  executing 

*LED  #1  is  the  left  most  LED,  LED  #8  is  farthest  to  the  right. 
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Figure  50  SIC  Bus  Connections 


Table  19 


SIC  BUS  SIGNALS 


SIGNAL  NAME 


FUNCTION 


B^2  CLK 

BPRIORITYN 

BSERIAL  DATA 

BRESP/CMD 

BDISCONN 

GROUND 

♦SV 

+25V 


SIC  system  clock  -2.4576  ^®^z 
Nameplate  priority  status  line 
Serial  data  communication  line 
Response/ command  enable  line 
SIC  reconfiguration  detection  line 
SIC  ground  (2  lines) 

SIC  +5Vdc  logic  power  (2  lines) 

SIC  ■^25Vdc  EPROM  programming  power  line 


4.2.2  SOFTWARE  DESIGN 

The  software  of  a  nameplate  consists  primarily  of  one  program, 
entitled  NFFROG,  which  executes  as  a  continuous  loop.  Whenever  a  nameplate 
Is  requested  to  run  Its  diagnostic,  the  program  DIAGPG  runs  "concurrently" 
with  the  program  NPPROG.  In  addition  to  the  two  programs,  several  Inter¬ 
rupt  routines  are  used  to  perform  functions  requiring  fast  response. 

A  flowchart  of  the  nameplate  program  NPPROG  Is  shown  In  Figure 
51.  Table  20  gives  a  brief  explanation  of  the  subroutines  called  by 
the  program.  Normal  execution  starts  when  the  nameplate  Is  reset  causing 
processing  to  vector  to  the  start  of  NPPROG.  The  subroutine  SYSINT  ini¬ 
tializes  the  nameplate's  variables  and  devices.  The  READ  subroutine  will 
wait  for  the  communication  Interrupt  handlers  to  receive  a  command  and  its 
associated  data.  The  wait  by  the  READ  subroutine  Is  terminated  when  a  read 
complete  flag  Is  set. 

The  CMDEXE  routine  decodes  the  command  and  calls  the  proper 
Internal  subroutine  to  execute  the  command  and  set  up  the  proper  data  for 
the  response.  Certain  commands  (write  data,  erase,  and  run  diagnostic) 
require  more  execution  time  than  others.  The  subroutines  of  CMDEXE 
associated  with  long  coimands  merely  set  up  data  and  flags  necessary  for 
the  Interrupt  handlers  (or  diagnostic  program)  to  perform  the  actual  exe¬ 
cution.  The  response  to  these  commands  is  used  to  acknowledge  their  receipt 
and  the  Initiation  of  their  execution.  Thus  the  time  from  the  reception  of 
the  last  of  a  command  to  the  start  of  the  response  will  always  be  the  same. 
Except  for  select,  deselect  and  "read  NF  address"  commands  which  are  always 
accepted  and  executed,  all  other  coimands  received  while  a  long  command  is 
being  executed  will  be  rejected  by  the  subroutines  of  CMDEXE.  Such  commands 
when  received  will  result  In  a  response  with  a  "NP  busy"  status. 


COMMENTS 


RESET  Interrupt  Vector 
Initiolize  System  Variables 


Get  Received  Command  and 
Data  i  Loop  if  DIA6PG 
not  Running  or  Read  not 
complete 

Diagnostic  Program  Active'? 


Resume  Diagnostic  Program 
or 

Execute  Command  and  set  up 
Response 

Check  if  this  NP  has  the 
highest  priority  of  selected 
NP’s 


If  highest  priority,  send 
response 


Deselect  here  on  Deselect 

Command  after  response 
sent. 


Figure  51  Nameplate  Main  Program 


Table  20 


NAMEPLATE  PROGRAM  DIRECTORY 


ROUTINE 

DESCRIPTION 

NPPROG 

Main  nameplate  program,  controls  execution 
of  other  routines 

SYSINT 

Initialization  routine 

READ 

Transfers  data  from  the  receiver  interrupt 
handler's  buffer  to  a  command  buffer 

CMDEXE 

Decodes  and  executes  commands 

Checks  if  any  NP  of  higher  priority  is 
selected 

WRITE 

Sends  response  to  the  SIC  bus 

CONDSL 

Deselects  this  NP  if  "deselect  nameplate" 
command  was  received 

RESUME 

Resumes  suspended  diagnostic  program 

DIAGPG 

NP  diagnostic  program 

SUSPEN 

Suspends  the  diagnostic  program 
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The  FRITS!  subroutine  is  called  by  the  main  program  to  check  the 
PRIORITY  IN  line.  If  this  line  is  low,  a  higher  priority  nameplate  (l.e. 
one  closer  to  the  system  processor)  is  selected  in  which  case  this  nameplate 
must  not  send  its  response.  The  nameplate's  timer  is  used  to  perform  a 
wait  after  the  RESP/CMD  line  goes  high  and  prior  to  the  checking  of  the 
PRIORITY  IN  line.  This  is  to  assure  that  all  nameplates  are  synchronized 
and  thus  the  PRIORITY  IN  line  is  stable. 

If  this  nameplate  has  highest  priority  (l.e.  it  is  selected  and 
its  PRIORITY  IN  line  is  high)  the  subroutine  WRITE  proceeds  to  send  the 
response  set  up  by  the  CMDEXE  subroutine. 

If  the  command  received  is  a  deselect  command,  the  subroutine 
CONDSL  will  then  proceed  to  deselect  this  nameplate.  This  assures  that 
when  the  nameplate  is  responding  with  a  status  of  "deselect  acknowledge" 
it  remains  selected  until  the  response  is  completely  sent. 

The  program  then  returns  to  the  READ  subroutine  to  check  for 
another  command.  This  loop  executes  continuously  unless  the  nameplate's 
diagnostic  program  DIAGPG  is  requested  to  execute.  A  flowchart  for  the 
diagnostic  program  is  presented  in  Figure  52.  Through  the  use  of  the 
subroutine  RESUME  and  SUSFEN,  the  diagnostic  program  and  NPPROG  are  able 
to  run  "concurrently"  as  co-routines.  Each  of  the  programs  NPPROG  and 
DIAGPG  use  these  subroutines  to  relinquish  CPU  control  to  the  other  at 
appropriate  places  in  their  execution.  DIAGPG  will  execute  for  a  time 
then  suspend  Itself  allowing  NPPROG  to  check  for  any  commands  received. 

If  there  are  none,  NPPROG  will  resume  the  diagnostic  program.  As  long  as 
there  are  commands  received  that  need  to  be  processed  the  DIAGPG  program 
must  wait. 
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Figure  52  Nameplate  Diagnostic  Program 


Interrupt  handling  routines  are  used  in  the  nameplate  to  perform 
functions  which  are  "transparent"  to  the  main  program.  These  routines  are 
listed  in  Table  21.  All  these  routines  process  data  buffers  and  set  flags 
to  indicate  their  status  of  execution  to  the  main  program.  Upon  completion, 
these  routines  return  to  the  program  at  the  point  of  interruption  so  that 
the  flow  of  the  main  program  remains  the  same. 

Communication  between  various  routines  Is  accomplished  through 
common  areas.  Tables  22,  23  and  24  Identify  the  common  blocks  of  vari¬ 
ables  and  their  functions.  Not  all  routines  need  access  to  all  common 
variables,  so  the  common  area  Is  divided  Into  two  local  common  areas  and 
a  global  common  area. 

Detailed  program  descriptions  including  flowcharts  for  the  name¬ 
plate  software  are  presented  in  Appendix  C,  Section  4-A. 

4.3  PROCESSOR  INTERFACE  TO  THE  SIC 

In  order  to  facilitate  interaction  of  programs  running  in  the  pro¬ 
cessor  with  electronic  nameplates  Installed  in  the  SIC,  an  interface  con¬ 
sisting  of  a  hardware  nameplate  interface  controller  board  and  a  software 
SIC  handler  has  been  developed.  The  SIC  handler  consists  of  a  set  of 
software  routines  designed  to  perform  all  control  and  monitoring  actions 
required  for  communication. 

4.3.1  NAMEPLATE  INTERFACE  CONTROLLER  DESIGN 

The  nameplate  Interface  controller  (NIC)  provides  the  hardware 
resources  required  to  Interface  the  processor  with  the  SIC  bus.  A  block 
diagram  for  the  nameplate  Interface  controller  is  presented  in  Figure  53. 
Operational  and  interface  specifications  for  the  NIC  are  presented  in 


Table  21 


NAMEPLATE  INTERRUPT  HANDLERS 


NAME  INTERRUPT  SOURCE 

NPPROG  RESETN 

CMDSTR  IRQN  from 

RESP/CMD  line 

RXDAT  RDA  of  serial 

receiver 

CMDSTP  Timer  Input 

Capture  from 
RESP/CMD  line 

Timer  Output 
Compare 


DESCRIPTION 

Start  execution  of  the  main 
program 

Initializes  serial  communication 
to  receive  a  command 

Stores  incoming  data  bytes  in 
temporary  buffer 

Terminates  command  reception 


Writes  data  to  EPROM,  or 
simulates  memory  erase. 


WRTERA 


Table  22 


NPCOMM  -  NAMEPLATE  GLOBAL  COMMON 


NA^E 

SIZE (bytes) 

DESCRIPTION 

THNPSL 

1 

This  NP  selected  flag 

NPSTAT 

1 

NP  status  byte 

ERST AT 

1 

Error  reason  status 

NPADDR 

1 

Assigned  NP  address 

NPBUSY 

1 

NP  busy  flag 

NPSYCT 

2 

NP  synchronization  count 

CMD 

1 

NP  command  being  processed 

CMDDAT 

18 

Data  for  command 

CMDCNT 

1 

Number  of  Data  bytes  received 
with  a  command 

TXCNT 

2 

Number  of  bytes  in  response 

TXDATA 

4 

First  4  bytes  of  response 

DIAGAD 

2 

Diagnostic  program  resume 
address 

DIADDT 

2 

Diagnostic  result  data 

DIAGSV 

4 

Diagnostic  save  buffer 

Table  23 

RDCOMM  -  READ  COMMAND  LOCAL  COMMON 


NAME 

SIZE (bytes) 

DESCRIPTION 

RDCOMP 

1 

Read  complete  flag 

RDSTAT 

1 

Status  of  received  data 

RDBYCT 

1 

Number  of  bytes  received 

READBF 

20 

Temporary  buffer  for  received 
data 

MEMORY  LOCAL  COMMON 


WRTCOM  -  WRITE 


NAME 


SIZE (bytes) 


DESCRIPTION 


WRTBUF 
RE C ADR 

WRTPTR 


15 

2 

1 


Data  to  be  written 

Starting  address  of  record  to 
be  written 

Pointer  into  WRTBUF 


DATTYP 


WRTFLG 

ERASCT 


1 


1 

1 


Type  of  data  to  be  written; 
Erase  membry,  write  memory 
data,  write  valid  record  bit 

Write  enable/disable  flag 

Count  of  time  interrupts  for 
erase 


WRTTRI 


1 


Write  re-try  count 


EXORCISER 

BUS 


Figure  53  Nameplate  Interface  Controller  Block  Diagram 


Tables  25  and  26.  The  NIC  may  be  used  In  any  processor's  chassis 
utilizing  the  Motorola  EXORclser  bus.  The  address  space  for  the  NIC  con¬ 
sists  of  8  bytes  (addresses  XXX0  through  XXX7 ) .  Of  these  addresses,  only 
addresses  XXX2  through  XXX5  are  actually  used.  The  symbol  X  designates  a 
hexadecimal  number  (0  through  F)  in  the  address  field  that  Is  user  select¬ 
able  through  switches. 

Theory  of  Operation 

This  section  provides  a  description  of  the  nameplate  Interface 
controller  block  diagram  shown  in  Figure  53.  Appendix  B,  Section  4-A  contains 
the  detailed  schematic  diagrams  for  this  controller. 

Address  Decoding  and  EXORclser  Bus  Buffers 

The  NIC  is  built  on  a  MEX68USM  Motorola  Universal  Support  Module 
which  provides  the  address  decoding  and  buffering  of  the  EXORclser  bus 
signals.  EXORclser  bus  address  signals  A15-A3  are  decoded  to  generate  a 
chip  select  signal  CSN.  This  signal  and  address  lines  A2,  A1  and  A0  are 
used  to  specify  the  NIC  register  requested.  Switches  SI,  S2,  and  S3  are 
used  to  select  the  upper  three  hexadecimal  digits  of  the  address.  Switch 
S4  should  always  be  set  to  zero.  One  is  referred  to  the  MEX68USM  user's 
guide  for  the  location  of  these  switches  and  for  detailed  information  per¬ 
taining  to  the  address  decoding  and  bus  buffering. 

Serial  Communications 

An  LSI  device,  the  Motorola  MC6850  (ACIA),  Is  used  to  convert  an 
8  bit  byte  of  parallel  data  Into  a  10  bit  serial  data  stream  (on  transmis¬ 
sion)  and  to  convert  10  bits  of  serial  data  Into  8  bit  parallel  data  (on 
reception) .  The  serial  data  Is  transmitted  and  received  at  a  rate  of  4800 
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Table  25 


NAMEPLATE  INTERFACE  CONTROLLER  SPECIFICATIONS 


CHARACTERISTIC 

SPECIFICATION 

Power  Requirements 

+5Vdc  +5%  @2.1  Amps 
+12Vdc  +5%  @  0.5  Amps 
-12Vdc  +5%  @  0.4  Amps 

Input  Signals 

TTL  voltage  compatible 

Output  Signals 

TTL  voltage  compatible 

Operating  Temperature 

0  to  70*C 

External  Interfaces 

Motorola  EXORciser  Bus  1 

SIC  Bus  2 

^  Refer  to  MC6800  EXORciser  User's  Guide* 
2  Refer  to  Appendix  B,  Section  4-B. 


L68 


ADDRESS  2 

FUNCTION 

X  X  X  2 

SIC  Status  Register 

X  X  X  3 

SIC  Control  Register 

X  X  X  4 

SIC  Communication  Control  Register 

X  X  X  5 

SIC  Communication  Data  Register 

^  See  Section4.i.2of  this  dociutent  for  a  full  explanation  of  the  use  of 
these  registers. 

2  Xroeans  this  hexadecimal  digit  is  switch  selectable  (0-F) . 
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baud.  The  ACIA  also  provides  a  modem  control  signal  which  Is  used  to 
Implement  the  RESP/CMD  signal  of  the  SIC  bus.  This  signal  Is  used  to  con¬ 
trol  the  operation  of  trl-state  buffers  which  direct  the  flow  of  data  on 
the  simplex  serial  data  line  of  the  SIC  bus.  One  Is  referred  to  Motorola's 
documentation  on  the  MC68S0  for  more  detailed  Information  on  Its  operation 
and  use. 

Clock  Generator  and  Divider 

A  A. 9152  MHz  crystal  and  a  clock  generator  Integrated  circuit  are 
used  to  generate  a  TTL  compatible  clock  signal,  called(J)2  CLK,  of  frequency 
2.A576  MHz  for  the  SIC  bus.  This  frequency  is  then  divided  by  32  to  create 
a  ^16  clock  for  the  serial  communication  ACIA.  Also  three  divider  outputs 
(1/128,  1/64,  1/32)  are  input  to  the  SIC  status  register  so  that  consecutive 
reads  of  the  register  may  be  used  to  determine  If  the  clock  circuit  Is 
functioning. 

SIC  Control  and  Status 

An  LSI  device,  the  Motorola  MC6821  (PIA) ,  is  used  as  the  SIC 
status  and  control  registers.  One  of  the  PIA's  8  bit  data  ports  Is  config¬ 
ured  as  an  Input  port  and  Is  used  to  monitor  several  Important  SIC  signal 
lines.  This  data  port  Is  called  the  SIC  status  register.  The  PIA's  control 
register  associated  with  this  data  port,  called  the  SIC  control  register, 
controls  the  modes  of  operation  of  the  SIC  and  generates  a  reset  signal 
for  the  SIC  bus.  The  reset  signal  kills  the  clock  signal  going  Into  the 
SIC  bus  and  causes  the  nameplate  to  reset. 

LM  Timer  Circuit 

Another  function  residing  on  the  nameplate  Interface  controller 


card  Is  the  LM  timer  circuit.  This  circuit  divides  the  LM's  1  MHz  system 

A 

clock  by  10  to  obtain  a  100  Hz  signal.  This  signal  triggers  an  interrupt 
through  the  PIA  on  the  nameplate  interface  controller  every  10  milliseconds 

4.3.2  SIC  HANDLER  DESIGN 

A  handler  was  developed  to  simplify  the  interface  between  tasks 
running  in  the  LM  and  the  control  registers  in  the  nameplate  interface 
controller.  A  calling  task  requests  a  service  (such  as  "load  the  name¬ 
plate's  directory")  from  the  handler  through  an  argument  list.  The  handler 
translates  this  request  into  a  sequence  of  nameplate  commands  required  to 
perform  the  function.  The  handler  also  performs  all  the  control  and  timing 
actions  required  by  the  SIC  communication  protocol  as  described  in  the 
preceedlng  sections.  Use  and  theory  of  operation  of  this  SIC  handler  are 
presented  in  Section  2.3.5. 


SECTION  5 


LINK  MANAGER 

5.1  DESIGN  OBJECTIVES 

The  Link  Manager  (LMG)  Simulator  described  In  this  document  Is  designed 
to  meet  the  following  objectives: 

1.  Verification  of  Link  Module  (LM)  operation,  demonstration  of  all 
functions  proposed  for  the  prototype  LM. 

2.  Ability  to  exercise  subsystems  Interfaced  through  the  Interface 
Configuration  Adapter  (ICA),  thus  verifying  the  operation  of  the  prototype 
ICA. 

3.  Different  operational  options: 

(a)  'real-time*  simulation  with  LM  -  fast  command  stream  from  a 
disk  file.  As  soon  as  the  execution  of  one  command  Is 
finished,  the  next  coimoand  from  the  disk  file  will  be  given 
to  the  LM. 

(b)  'manual'  operation  of  LM  -  commands  Input  from  a  CRT 
manually.  The  results  can  be  seen  In  steps  at  the  CRT. 

(c)  'combined'  operation  -  'real-time'  and  'manual'  operation 
can  be  switched  back  and  forth. 

(d)  'repetitive'  operation  -  operations  can  be  looped  at  high 
speed  for  exercising  and  debugging. 


4.  Facilities  to  easily  set  up  a  simulation  or  repetitive  test,  or 
set  up  a  consnand  stream  for  'real-time*  operation. 

5.  Ease  of  use,  with  simplified  procedures  for  operating  the  LMG 
simulator. 


6.  Ease  of  modification.  Software  will  be  modular  so  as  to  facilitate 
future  modifications  to  the  LMG  simulator. 

5.2  SOFTWARE  DESIGN  OVERVIEW 


5.2.1  GENERAL  FEATURES 

In  order  to  satisfy  the  objectives  described  in  5.1,  the  design 
is  approached  in  the  following  way: 

1.  The  LMG  simulator  is  con?>rised  of  two  real-time  tasks  running 
under  the  RSX-llM  operating  system  on  a  PDP-11/70  computer.  The  Command 
Interpreter  task  Interprets  and  executes  commands  given  to  the  LMG  simulator. 
The  Shared  Memory  Display  task  Interprets  and  displays  the  contents  of 
shared  memory. 

2.  The  high  level  language  FORTRAN  IV  is  used  wherever  possible. 

3.  Structured,  modular  programming  techniques  are  employed  for 
ease  of  debugging  and  modification. 

4.  The  simulator  is  Interactive  and  conversational  to  facilitate 
use  of  the  system. 

5.  An  output  log  file  on  the  disk  may  be  used  to  record  all 
transactions  during  a  simulation.  It  can  be  used  for  debugging  or  demon¬ 


stration  purposes. 


6.  Some  commands  other  than  those  of  the  LM  and  LMG,  called 
'Maintenance  Port'  (MP)  commands,  are  defined  to  support  the  debugging  and 
demonstration  features  of  the  system.  The  LM,  LMG  and  MP  commands  supported 
are  detailed  In  Section  5.3. 

7.  Two  command  Input  modes  are  offered.  Commands  can  be  Input 
either  from  the  CRT  or  a  disk  file.  Commands  and  parameters  Input  through 
the  CRT  can  be  recorded  to  a  disk  file  to  be  used  at  a  later  time  as  a  disk 
Input  comnand  file  for  'real-time'  or  repetitive  simulations. 

8.  Indirect  command  files  are  used  to  facilitate  the  demonstra¬ 
tion.  The  Indirect  command  can  contain  all  the  commands  and  parameters 
that  are  necessary  for  performing  the  demonstration. 

9.  The  DEC  DRll-C  General-Purpose  Interface  Module  is  used  as 
an  Interface  to  transfer  data  between  the  PDP-11/70  and  the  SM  of  the  LM. 

The  DRll-C  Driver  is  written  in  assembly  language  and  is  installed  as  a 
loadable  driver  In  the  RSX-llM  operating  system. 

5.2.2  STRUCTURE  OF  THE  SIMULATOR 

Figures  54  and  55  are  system  diagrams  of  the  LMG  simulator. 

There  are  two  tasks  in  the  LMG  simulator  system:  Command  Interpreter  (Cl) 
task  and  SM  Display  (SMD)  task.  The  Cl  task  contains  four  major  modules: 
command  Identification  module,  command  execution  module,  local  processing 
module  and  SM  handler  module.  The  command  identification  module  receives 
and  Interprets  comnands.  The  command  execution  module  Includes  the 
Maintenance  Port  (MP)  command  routines,  LMG  command  routines  and  LM  command 


routines. 


Output  Log  File 
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Figure  55  Block  Diagram  of  LMG  Simulator 


These  routines  execute  specific  functions  of  the  MP,  LMG  and  LM  commands. 

The  local  processing  module  Includes  data  transfer  routines  to  perform  the 
data  transfer  functions  between  the  LMG  and  the  subsystem.  The  shared 
memory  handler  Is  a  subroutine  used  to  access  the  shared  memory  through  the 
DRll-C  driver.  The  SMD  task  uses  the  DRll-C  driver  to  read  the  data  in  the 
SM,  and  then  interprets  it  and  displays  it  on  the  CRT. 

The  DRll-C  driver  is  an  I/O  driver  written  for  the  RSX-llM  oper¬ 
ating  system  tj  transfer  data  between  the  DRll-C  and  the  SM  in  the  LM. 
Utility  Library  (UTILIB)  is  a  collection  of  several  utility  routines  shared 
by  the  Cl  task  and  SMD  task. 

5. 2. 2.1  Cl  Task 

The  Cl  task  runs  on  CRT  #1.  Commands  and  parameters  can  be  input 
from  CRT  or  disk.  The  command  identification  module  receives  a  command  and 
parameters,  interprets  It,  and  executes  it  by  calling  the  appropriate  com¬ 
mand  module.  It  echoes  the  command  and  parameters  on  the  CRT  if  in  disk 
input  mode,  records  the  command  and  parameters  to  a  new  command  file  if  in 
creating  command  file  mode,  and  records  all  the  transactions  during  a 
simulation  to  a  log  file  if  there  is  one  open. 

The  command  module  gives  command  and  parameters  to,  and  handshakes 
with,  the  SM  by  calling  the  SM  handler  to  call  the  DRll-C  driver.  Some  LMG 
commands  can  be  executed  Just  by  calling  a  sequence  of  the  LMG  modules.  The 
'LOCAL*  command  will  cause  the  coranand  identification  module  to  call  the 
LF  module  to  perform  data  transfer  functions  to/from  the  LM  using  the  SM 
handler  and  DRll-C  driver. 

5. 2. 2. 2  SMD  Task 

The  SMD  task  runs  on  CRT  iH  to  continually  interpret  and  display 
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the  contents  of  the  SM  through  calls  to  the  DRll-C  driver.  The  display  of 
the  SM  on  CRT  #2  Is  In  an  easy- to-read.  Interpreted  format.  Command  name, 
processing  status,  special  conditions,  and  all  the  significant  contents  of 
the  SM  are  shown. 

5.2.2. 3  Data  Transfer  Routines 

The  data  transfer  routines  are  application  programs  to  perform 
the  data  I/O  functions.  There  are  four  kinds  of  data  I/O:  sequential  In¬ 
put,  sequential  output,  refreshed  Input  and  refreshed  output.  The  data  I/O 
task  should  be  downloaded  to  the  LM  first.  The  LOCAL  command  causes  one  of 
the  data  transfer  routines  to  communicate  with  the  data  I/O  task  running  in 
the  LM  to  transfer  data  between  the  LMG  and  the  subsystem. 

5. 2. 2. A  Utility  Routines 

The  utility  routines  contain  many  frequently  used  subroutines, 
commonly  used  by  the  Cl  task  and  the  SMD  task. 

5. 2. 2. 5  SM  Handler  and  DRll-C  Driver 

The  SM  handler  is  a  subroutine  which  has  several  entry  points  to 
access  different  places  in  the  SM  using  the  DRll-C  driver.  The  DRll-C 
driver  handshakes  with  the  SM  hardware  to  implement  data  transfer  between 
the  LMG  simulator  (PDF-11)  and  the  LM. 

5.3  COMMAND  INTERPRETER  (Cl)  TASK 

Figure  56  is  the  structure  of  Cl  task.  The  Cl  task  includes  a  main 
program  (command  identification  module)  and  many  subroutines  (for  example, 
LMG  command  routines,  LM  conmand  routines,  MP  command  routines,  LP  module, 
SM  handler).  It  interprets  conoands  and  executes  them  through  the  appro- 
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prlate  nodules. 

The  Cl  task  Is  Initially  in  CRT  Input  node,  and  can  be  switched  between 
CRT  and  disk  Input  nodes.  It  can  be  directed  to  create  a  new  conmand  file. 
Also,  the  action  to  be  taken  on  errors,  whether  to  stop  or  continue,  can  be 
selected  by  the  user. 

The  Cl  task  perforns  initialization  first.  The  initialization  steps 
include  requests  at  CRT  jifl  for: 

1.  the  cursor  hone  up  control  characters  for  the  teminal, 

2.  the  type  of  transcript  to  the  CRT  desired  for  disk  input  node, 

3.  the  output  log  file  name,  if  there  is  to  be  one. 

The  Cl  task  is  thenready  for  a  consnand. 

When  the  Cl  task  receives  a  comnand,  it  first  checks  the  validity  of 
the  comnand.  If  the  command  is  valid,  it  is  given  to  the  conmand  execution 
module  for  execution.  If  the  command  is  a  'LOCAL*  command,  a  data  transfer 
application  subprogram  will  be  invoked  to  perform  the  data  transfer  function 
between  the  LMG  and  the  subsystem. 

If  the  input  command  begins  with  the  character  it  is  an  indirect 

command  file  rather  than  a  conmand.  The  indirect  command  file  procedure 
opens  the  indirect  conmand  file  and  processes  it  using  the  command  process 
module,  as  the  dashed  line  indicates  in  Figure  56.  If  an  error  or  failure 
occurs,  the  Cl  task  processes  it  to  display  the  error  or  failure  message. 

The  utility  routines  are  used  to  support  the  Cl  task  performing  its  function. 

There  are  three  categories  of  commands:  LMG  conmand,  LM  function  com¬ 
mand  and  MP  conmand.  The  LMG  commands  are  listed  in  Table  27.  The  LM 
function  conmands  are  listed  in  Table  28.  The  MP  conmands  are  listed  in 


Table  27 

LMG  COMMANDS 

Comnand 

Function 

SMDIAG 

Perform  SM  diagnostic  function 

LOCAL 


Request  data  transfer  application 
program  to  transfer  data  between 
the  LMG  and  the  subsystem. 


Table  28 


LM  FUNCTION  COMMUID 


Command 

Function  within  LM 

NOOP 

No  operation 

PRGMLD 

Load  non-resident  task 

RUN 

Run  non-resident  task 

STOP 

Stop  non-resident  task 

CONFIG 

Configure  selected  subsystem 

XFRTBL 

Transfer  LM  system  tables  to/from  LMG 

CANCEL 

Cancel  the  previous  command  that  is  pending 

RESET 

Reset  CMDITR  and  ICA 

RESTRT 

Jump  to  power  up  restart  location 

STATUS 

Clear  input  buffer  request  bit  and  service 
request  bit  in  flag  mode 

NPINIT 

Request  NP  handler  to  initialize  NP's 

NPDIAG 

Same  as  NPINIT 

Table  29  .  All  the  coimnands  that  will  access  the  SM  utilize  the  SM  handler. 
A  brief  description  of  each  command  is  given  in  the  following.  Full  details 
for  using  each  command  are  given  in  the  RLUDS  User's  Manual. 

5.3.1  LMG  COMMANDS 

When  the  LMG  simulator  receives  a  LMG  command  at  CRT  //I,  it  will 
execute  this  command  by  itself,  or  by  issuing  a  series  of  LM  function  com¬ 
mands  to  the  LM,  or  by  a  combination  of  both  methods. 

1.  SMDIAG:  The  SMDIAG  command  executes  a  diagnostic  on  shared 

memory,  verifying  the  ability  to  read  from  and  write  to  the  shared  memory. 

It  also  checks  the  hardware  Interrupt  caused  in  the  LM  when  the  LMG  writes 
an  LM  function  command  into  SM. 

2.  LOCAL:  The  LOCAL  command  causes  a  data  transfer  applica¬ 

tion  subprogram  to  perform  data  transfer  between  the  LMG  and  the  subsystem. 
Before  issuing  the  'LOCAL*  command,  a  data  I/O  task  should  be  loaded  to  the 
LM  and  run  to  communicate  with  the  data  transfer  application  subroutine  in 
the  LMG. 

5.3.2  LM  FUNCTION  COMMANDS 

When  the  LMG  receives  an  LM  function  command,  it  will  request  the 
LM  to  execute  this  conmand.  The  lil  will  return  the  status  of  the  command 
execution  and/or  the  results  of  execution  to  the  IMG. 

1.  NOOP:  This  command  doesn't  request  the  LM  to  take  any 

action.  It  is  used  to  provide  the  LMG  with  a  means  of  exercising  the  com¬ 
mand  handshake  without  causing  anything  to  happen. 
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Coamand 


CLOLF 


OPICF 


CLICF 


OPOCF 


CLOCF 


CREATE 


NOCRET 


STPERR 


CNTERR 


MPSTAT 


REWIND 


WRITE 


SETTIM 


Table  29 


MP  COMMANDS 


Function 


Input  from  CRT 
Input  from  disk 

Close  an  old  log  file  and  open  a  new  one, 
If  wanted. 

Open  input  command  file 
Close  input  command  file 
Open  output  command  file 
Close  output  command  file 
Creating  Output  Command  File 
Stop  creating  output  command  file 
Stop  on  error 


Continue  on  error 


Output  Maintenance  Port  Status 
Rewind  input  coamand  file 
Exit  program 


Write  data  to  SM 


Read  data  from  SM 


Duaip  all  the  data  in  SM  on  the  CRT 
Set  PDP-11  system  time  to  LM 


v'.'wr  A.'.' '.v ■ 
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2.  PRGMLD:  This  command  requests  the  LM  to  download  a  nonresident 
task  from  the  LMG  or  upload  a  nonresident  task  from  the  NP.  The  nonresi¬ 
dent  task  can  be  a  data  1/0  task  or  a  subsystem  diagnostic  task. 

3.  RUN:  This  command  requests  the  LM  to  activate  the  non¬ 

resident  task  In  the  LM. 

4.  STOP:  This  command  requests  the  LM  to  terminate  the  run¬ 

ning  of  the  nonresident  task  In  the  LM. 

5.  CONFIG:  This  connand  requests  the  LM  to  cause  the  ICA 
handler  to  con^gure  the  ICA  with  configuration  parameters  from  either  the 
LMG  or  the  NP. 

6.  XFRTBL:  This  command  requests  the  LM  to  transfer  LM  system 

tables  to  or  from  the  LMG.  The  LMG  Interprets  any  table  obtained  from  the 
LM  and  displays  It  on  the  CRT  in  an  easy  to  read  format. 

7.  CANCEL:  This  command  requests  the  LM  to  stop  the  execution 

of  any  other  command  already  in  progress. 

8.  RESET:  This  command  requests  the  LM  to  reset  the  state  of 

the  LM's  CMDITR  task  and  of  the  ICA  hardware. 

9.  RESTRT:  This  command  requests  the  LM  to  jump  to  Its  power 
up  restart  location. 

10.  STATUS:  This  command  clears  the  service  request  bit  In  the 
status  alert  byte  and  requests  the  LM  to  clear  the  Input  buffer  request  bit 
In  flag  mode  data  transfers. 


11.  NPINIT:  This  conmand  requests  the  NP  handler  to  reset  all 
the  NPs  and  cause  each  NP  to  run  its  Internal  diagnostic.  The  LMG  inter¬ 
prets  and  displays  the  diagnostic  result  on  the  CRT. 

12.  NPDIAG:  This  command  is  identical  to  the  NPINIT  command. 

5.3.3  MP  COMMANDS 

MP  commands  Implement  features  for  debugging  and  demonstration  of 
the  RLU  system.  They  also  Implement  utility  functions  in  the  LMG  simulator. 

1.  CRT:  This  command  directs  that  commands  and  parameters 

will  be  input  from  the  CRT. 

2.  DISK:  This  command  directs  that  commands  and  parameters 

will  be  input  from  the  disk  (an  input  command  file). 

3.  CLOLF:  This  command  closes  an  old  output  log  file  and 

allows  the  option  to  open  a  new  output  log  file. 

4.  OPICF:  This  command  opens  an  input  command  file  for  use 

in  disk  input  mode. 

5.  CLICF:  This  command  closes  the  opened  input  command  file. 

6.  OPOCF:  This  command  opens  an  output  command  file  for  re¬ 

cording  the  command  stream  (for  future  use  as  an  input  command  file). 

7.  CLOCF:  This  command  closes  the  opened  output  command  file. 

8.  CREATE:  This  command  puts  the  system  into  the  creating 

mode.  All  the  commands  and  parameters  will  be  recorded  in  the  output  com¬ 


mand  file. 


9. 


NOCRET:  This  comaand  puts  the  system  Into  the  non-creating 


mode. 

10.  STPERR:  This  command  causes  disk  input  mode  execution  to 
stop  if  an  error  occurs.  At  the  same  time,  the  disk  input  mode  will  be 
switched  to  CRT  input  mode. 

11.  CNTERR:  This  command  causes  disk  input  mode  execution  to 
continue  even  if  an  error  occurs. 

12.  MPSTAT:  This  command  will  display  the  maintenance  port 

status  on  the  CRT.  The  ^^P  status  includes  the  files  opened,  stop-on-error 
or  contlnue-on-error  condition,  creating  or  non-creating  mode,  CRT  input  or 
disk  input  mode. 

13.  REWIND:  This  command  rewinds  the  input  command  file  to  the 
beginning. 

14.  EXIT:  This  command  closes  all  opened  files  and  terminates 

the  Cl  task. 

15.  WRITE:  This  comnand  writes  a  block  of  data  in  HEXASCII 

format  into  the  SM. 

16.  READ:  This  command  reads  a  block  of  data  from  the  SM  and 

displays  it  in  HEXASCII  format  on  the  CRT. 

17.  DUMP:  This  comnand  reads  all  the  data  in  the  SM  and  dis¬ 

plays  it  in  HEXASCII  format  on  the  CRT. 

18.  SETTIM:  This  command  gets  the  time  from  PDP-11  system  and 
sets  the  time  in  the  IM.. 
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5.4  SHARED  MEMORY  DISPLAY  (SMD)  TASK 


The  SMD  task  Is  a  program  written  to  cont.lnually  Interpret  and  display 
the  contents  of  the  SM  on  a  CRT.  Figure  57  Is  the  structure  of  SMD  task. 

The  SMD  task  performs  Initialization  first.  The  Initialization  steps 
Include  requests  at  CRT  //2  for: 

1.  The  cursor  home  up  control  characters  for  the  terminal. 

2.  The  refresh  rate  for  updating  the  SM  display  on  the  CRT. 

At  the  user-selected  refresh  rate  the  entire  contents  of  the  SM  will 
be  copied  Into  a  buffer  In  the  SMD  task  using  the  DRll-C  driver.  Then  the 
SMD  task  Interprets  the  data  and  displays  It  In  HEXASCll  on  the  CRT. 

The  format  of  the  shared  memory  display  Is  shown  In  Figure  58.  The 
Information  displayed  Includes: 

1.  The  most  recent  LM  function  command  name  and  Its  processing  status. 

2.  Information  on  special  conditions  such  as  a  service  request,  LM 
alert,  NF  alert,  ICA  alert,  LA  alert  and  subsystem  down. 

3.  Connand  and  status  bytes  In  HEXASCll  format.  The  command  bytes 
Include  the  LM  function  command  and  the  data  transfer  command. 

The  status  byte  Include  LM  function  status,  data  transfer  status, 
status  alert,  LM  status,  MP  status,  ICA  status,  and  LA  status. 

4.  Contents  of  the  LM  buffer,  1/0  buffer  1  and  1/0  buffer  0  In  HEXASCll. 

5.5  DATA  TRANSFER  ROUTINES 

The  data  transfer  routines  are  application  routines  to  transfer  data 
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Figure  57  Structure  of  Shared  Memory  Display  Task 
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Figure  58  Layout  of  Shared  Memory  Display 
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between  the  LMG  and  the  subsystem.  A  data  I/O  nonresident  task  should  be 
loaded  into  the  LM  from  either  the  LMG  or  the  NP.  The  nonresident  task 
handshakes  through  SM  with  the  data  transfer  routines  to  perform  data 
transfer  to  or  from  LMG.  There  are  four  types  of  data  transfers:  sequen¬ 
tial  input,  sequential  output,  refreshed  input  and  refreshed  output. 

Figure  59  shows  the  protocol  of  the  data  transfer  handshake.  Figure  60 
shows  the  structure  of  the  data  transfer  modules.  The  details  of  each  are 
given  below. 

5.5.1  DATA  TRANSFER  HANDSHAKE  PROTOCOL 

Figure  59  shows  the  command  byte  and  status  bytes  used  in  the 
data  transfer  handshake.  Cl  is  the  data  transfer  command  byte.  SI  and  S0 
are  the  data  transfer  status  bytes. 

The  LMG  begins  a  data  transfer  operation  by  performing  a  read- 
modify-wrlte  on  status  by  SI.  After  the  read  portion,  the  LMG  checks  the 
RDY0  and  RDYl  bits  to  see  if  Buffer  0  (output  buffer)  is  available  or 
Buffer  1  (input  buffer)  is  available.  If  the  desired  buffer  is  available, 
the  LMG  sets  REQ0  or  REQl  to  Indicate  which  is  being  taken  and  writes  SI 
back  to  SM.  It  then  writes  S^  to  SM  to  give  the  number  of  bytes  (WSC)  to 
be  transferred.  After  the  data  is  transferred,  the  LMG  writes  command  byte 
Cl  to  SM,  cau8li:g  an  Interrupt.  In  Cl,  lOB  Indicates  whether  Buffer  1  or 
0  is  being  released,  and  REF^l  if  buffer  being  released  is  refreshed. 
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Data  Transfer  Command  Word: 


15  9  8  7  3  0 


Data  Transfer  Status  Word: 


15 

14 

13 

9 

8 

D 

H 

11 

H 

11 

E 

m 

D 

Q 

n 

B1 

Icl 

im 

SI 


WSC 


spr 


Data  Transfer  Handshake: 

1.  LMG  sends  C0  to  LM,  generatinq  an  interrupt 
LA  =  4-bit  Link  Address 

INIT  =  1  to  indicate  initiation  of  message  transfer 

2.  LMG  performs  read-modify-write  on  SI 

FLG  =  1  if  subsystem  is  flagged  as  down 

RDY0  -  1  if  buffer  0  is  available 

RDYl  -  1  if  buffer  1  is  available 

REQ0  *  1  to  indicate  buffer  0  is  being  taken 

REQl  =  1  to  indicate  buffer  1  is  being  taken 

3.  LMG  writes  S0  to  LM  (output)  or  reads  S0  from  LM  (input) 
WSC  =  word  subcount,  no.  of  words  being  transferred 

4.  LMG  transfers  data 

5.  LMG  sends  Cl  to  LM,  generating  an  interrupt 


ERH  B  1  if  an  error  was  encountered 

ZOB  >  1  to  release  buffer  1,  0  to  release  buffer  0  (single-buffered  1/0) 
REF  ■  1  if  buffer  to  be  released  is  refreshed 


Figure  59  Data  Transfer  Handshake  Protocol 


Figure  60  Structure  of  the  Data  Transfer  Modules 


5.5.2 


DATA  TRANSFER  MODULES 


Following  Is  the  handshake  sequence  for  each  of  the  data  transfer 

modules . 

5. 5. 2.1  Sequential  Input 

1.  LMG  requests  Input  buffer  (If  RDYl-1  and  FLG>0,  then  LMG 
sets  RDYl-0  and  REQl-1). 

2.  LMG  reads  the  WSC  (word  subcount)  and  data  from  SM. 

3.  LMG  Issues  STATUS  function  comnand  to  release  buffer  and 
clear  asynchronous  service  request. 

5. 5. 2. 2  Sequential  Output 

1.  LMG  requests  output  buffer  (If  RDY0»1  and  FLG*0,  then  LMG 
sets  RDY0O0  and  REQ0*1). 

2.  LMG  writes  WSC  and  data  into  SM. 

3.  LMG  writes  data  transfer  command  Cl  (00^^),  causing  an  In¬ 
terrupt  to  the  LM  to  release  buffer  0. 

5. 5. 2. 3  Refreshed  Input 

1.  LMG  requests  Input  buffer  (If  RDYl-1  and  FLG-0,  then  LMG 
sets  RDYl-0  and  REQl-1). 

2.  LMG  reads  WSC  and  data  from  SM. 

3.  LMG  writes  data  transfer  command  Cl  >  causing  an  In¬ 

terrupt  to  the  LM  to  release  the  buffer. 
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5. 5. 2. 4  Refreshed  Output 

1.  LMG  requests  output  buffer  (if  RDY0-1  and  FLG-0,  then  LMG 
sets  RDY0»0  and  R£Q0«1) . 

2.  LMG  writes  WSC  and  data  Into  SM. 

3.  LMG  writes  data  transfer  command  Cl  >  causing  an  In¬ 

terrupt  to  the  LM  to  release  the  buffer. 

5.6  UTILITY  ROUTINES 

The  utility  routines  are  stored  In  a  file  called  UTILIB.  These  rou¬ 
tines  are  frequently  used  by  or  shared  by  other  programs  or  subroutines. 
They  can  be  classified  Into  general  categories  by  their  functions.  These 
general  categories  are  described  below. 

5.6.1  DATA  CONVERSION  ROUTINES 

These  routines  perform  general  purpose  data  conversion  tasks: 

1.  Conversion  between  binary  data  and  HEXASCII  characters. 

2.  Conversion  between  BCD  data  and  BCD  ASCII  characters. 

3.  Conversion  between  decimal  values  and  2's  complement  binary 
or  offset  binary  values. 

4.  Conversion  of  binary  data  to  BCD  ASCII  characters. 

5.6.2  DATA  TRANSFER  ROUTINES 

These  perform  the  following  handshake  protocol  functions: 


1.  Request  I/O  buffer. 


2. 


Read  or  write  WSC. 


3.  Read  or  write  data. 

4.  Write  Cl  to  interrupt  LM. 

5.6.3  MISCELLANEOUS  UTILITY  ROUTINES 

Some  of  the  major  functions  performed  by  this  last  category  in¬ 
clude: 


1.  Walt  and  check  the  status  of  LM  function  command  execution. 

2.  Clear  service  request  bit. 

3.  Clear  the  screen  of  the  terminal. 

4.  Check  one  bit  of  a  byte. 

5.  Read  a  parameter  and  check  whether  its  value  falls  in  the 
predefined  range. 

6.  Logical  function  'YES'  to  facilitate  answering  yes-or-no 
questions. 


5.7  SM  HANDLER 

The  Shared  Memory  Handler  (SMH)  is  a  subroutine  which  provides  many 
entry  points  for  other  programs  to  call  to  access  the  SM.  The  SM  has  256 
bytes,  with  addresses  from  0  to  255.  Each  SMH  entry  point  implies  a  start¬ 
ing  address  for  accessing  SM  through  the  DRll-C  driver.  The  number  of 
bytes  to  be  accessed  and  the  function  to  be  performed  (read,  write  or  read- 
modlfy-write)  are  passed  as  arguments  in  the  call  to  the  entry  point.  Us¬ 
ing  symbolic  entry  points  for  each  type  of  SM  access  relieves  the  calling 


program  of  the  responsibility  for  knowing  any  SM  addresses  or  handshake 
protocols. 

5.7.1  SM  Sandler  functions 

Described  below  are  the  functions  of  each  of  the  entry  points  of 
the  SMH  listed  in  Table  30. 

WFCMD:  This  entry  point  is  used  to  write  the  LM  function  com¬ 

mand  byte  to  the  SM. 

RFCMD:  This  entry  point  is  used  to  read  the  LM  function  com¬ 

mand  byte  from  the  SM. 

RFSTS:  This  entry  point  is  used  to  read  the  LM  function  status 

byte  from  the  SM. 

WXCMD:  This  entry  point  is  used  to  write  the  data  transfer 

command  byte  (Cl)  to  the  SM. 

RXCMD:  This  entry  point  is  used  to  read  the  data  transfer  com¬ 

mand  byte  from  the  SM. 

RSI:  This  entry  point  is  used  to  read  the  data  transfer  status 

byte  SI  from  the  SM. 

WSl:  This  entry  point  is  used  to  write  the  data  transfer 

status  byte  SI  to  the  SM. 

RWMSl:  This  entry  point  is  used  to  do  read-modify-write  on  data 


transfer  status  byte  SI. 


Table  30 


FUNCTIONS  OF  SMH 


Entry  N2une 

Function 

WFCMD 

Write  LM  function  comnand  byte 

RFCMD 

Read  LM  function  command  byte 

RFSTS 

Read  LM  function  status  byte 

WXCMD 

Write  data  transfer  command  byte 

RXCMD 

Read  data  transfer  command  byte 

RSI 

Read  data  transfer  status  byte  SI 

WSl 

Write  data  transfer  status  byte  SI 

RWMSl 

Read-modify-write  data  transfer  status  byte  SI 

WTXS0 

Write  data  transfer  status  byte  S0 

RTXS0 

Read  data  transfer  status  byte  S0 

WFBUF 

Write  data  to  LM  function  buffer 

RFBUF 

Read  data  from  LM  function  buffer 

UXBUF 

Write  data  to  data  I/O  buffer 

RXBUF 

Read  data  from  data  I/O  buffer 

BLASTS 

Read  LA  status  byte 

RICSTS 

Read  ICA  status  byte 

RLMSTS 

Read  LM  hardware  status  byte 

RNPSTS 

Read  NP  hardware  status  byte 

RSTSAL 

Read  status  alert  byte 

WSTSAL 

Write  status  alert  byte 
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WTXS0:  This  entry  point  is  used  to  write  the  data  transfer 


status  byte  S0  to  the  SM. 


RTXS0:  This  entry  point  is  used  to  read  the  data  transfer  status 


byte  S0  from  the  SM. 


WFBUF:  This  entry  point  is  used  to  write  data  to  LM  function 

buffer.  The  number  of  data  bytes  is  limited  to  64. 


RFBUF:  This  entry  point  is  used  to  read  data  from  the  LM  func¬ 

tion  buffer.  The  number  of  data  bytes  is  limited  to  64. 

WXBUF:  This  entry  point  is  used  to  write  data  to  an  I/O  buffer. 

Buffer  0  or  buffer  1  can  be  selected.  The  number  of  data  bytes  is  limited 
to  64. 


RXBUF:  This  entry  point  is  used  to  read  data  from  an  I/O  buffer. 

Buffer  0  or  buffer  1  can  be  selected.  The  number  of  data  bytes  is  limited 
to  64. 


RLASTS:  This  entry  point  is  used  to  read  the  LA  status  byte  from 


the  SM. 


RICSTS:  This  entry  point  is  used  to  read  the  ICA  status  byte 


from  the  SM. 


RLMSTS:  This  entry  point  is  used  to  read  the  LM  hardware  status 


byte  from  the  SM. 


KNPSTS:  This  entry  point  is  used  to  read  the  NF  hardware  status 


byte  from  the  SM. 
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RSTSAL:  This  entry  point  is  used  to  read  the  status  alert  byte 

from  the  SM. 

WSTSAL:  This  entry  point  is  used  to  write  the  status  alert  byte 

to  the  SM. 

5.8  DRll-C  DRIVER 

The  DRll-C  driver  is  an  RSX-llM  I/O  peripheral  driver  written  in  assem¬ 
bly  language.  It  drives  the  DEC  DRll-C  board  which  Interfaces  the  LM  with 
the  DEC  PDF  11/70  that  simulates  the  LMG. 

The  DRll-C  board  has  two  output  control  lines  labled  CSR0  and  CSRl  and 
two  input  control  lines  labled  AREQ  and  BREQ.  The  BREQ  line  is  unused. 

The  high  order  byte  of  the  16  data  lines  is  used  as  the  SH  address.  The 
low  order  byte  of  the  16  data  lines  is  used  as  the  data  for  input  or  output. 

Figure  61  is  a  diagram  of  the  handshakes  for  read,  write  and  read- 
modify-write  operations.  For  the  'write'  function,  the  driver  sets  CSRl 
and  puts  valid  address  and  data  in  the  output  register.  Then  the  driver 
sets  CSR0  to  Initialize  the  data  transfer.  AREQ  should  be  low  before  set¬ 
ting  the  CSR0.  The  driver  then  exits  and  is  recalled  when  AREQ  goes  high 
generating  an  Interrupt.  The  driver  then  resets  CSR0  and  waits  in  a  wait 
loop  for  AREQ  to  return  low.  Timeout  checks  are  wherever  needed.  The 
'read'  and  'read-modlfy-wrlte'  functions  are  similar  to  'write',  as  indi¬ 
cated  in  Figure  61.  The  flowchart  for  the  driver  is  given  in  Appendix 
C,  Section  5-A. 

5.9  DEMONSTRATION  EXAMPLE 

A  serial  RLU  test  example  is  given  in  this  section  to  Illustrate  the 


use  of  the  simulator.  Figure  62,  63  and  64  are  Indirect  command  flies 

named  R2A.DEM,  R2B.DEM  and  R2C.DEM,  respectively.  Figure  65  Is  a  trans¬ 
cript  of  CRT  //I  during  this  example.  Figure  66  shows  the  SM  display  on 
the  CRT  //2  at  three  points  In  the  example.  Those  characters  with  underlines 
are  Input  from  the  CRT. 

In  Figure  65  (a) ,  the  Cl  task  does  Initialization  before  prompting 
for  a  command.  The  first  command  @R2A  leading  with  character  @  Indicates 
that  R2A  is  an  Indirect  command  file.  The  Indirect  command  file  R2A  as 
shown  In  Figure  62  Is  opened  and  the  command  stream  In  this  file  Is  exe¬ 
cuted.  Each  line  In  the  Indirect  coimnand  file  Is  a  command  or  parameter. 

(If  a  line  begins  with  the  character  ;  or  ! ,  the  Cl  task  treats  It  as  a 
comment  and  Ignores  It.)  Because  the  subsystem  Is  not  attached  to  the  LM 
at  first,  the  return  status  from  the  NPINIT  command  Is  failure  code  -10. 

At  the  same  time,  referring  to  Figure  66  (a),  the'NP  ALERT*  message  is 
shown  on  the  CRT  //2  screen  as  a  special  condition  to  Indicate  that  no  sub¬ 
system  Is  connected  to  the  LM.  The  LH  function  command  NPINIT  and  return 
status  failure  code  -10  are  also  displayed  on  the  CRT.  The  transcript  is 
displayed  on  the  CRT  #1  because  of  the  selection  of  'full  transcript  on  CRT* 
during  the  Initialization.  If  'brief  transcript  on  CRT'  Is  chosen,  only 
the  commands  and  parameters  will  be  displayed  on  CRT.  If  'no  transcript  on 
CRT'  Is  chosen,  nothing  will  be  displayed  on  CRT  except  a  return  status  of 
'failure'. 

Now  we  connect  the  serial  subsystem  to  the  LM  and  Issue  the  @R2A  com¬ 
mand  again.  All  the  procedures  performing  the  serial  subsystem  test  can  be 
seen  on  the  CRT  //I  as  shown  In  Figure  65b.  The  NPINIT  Initializes  and 

diagnoses  the  NP.  The  diagnostic  result  shows  that  the  NP  has  8  free  re- 
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;TEST:  SERIAL  I^.'PiJT/i:iUTFnT  (UP  LOAD  FROM  NP) 

;  INPUT:  CiROUF  B  ;  OUTPUT:  GROUP  A 

• 

{INITIALIZE  NP 

f 

NPINIT 

• 

{LOAD  DIO  TAOK  FROM  NP 

» 

PRGMLD 

DIO 

NP 

> 

{CONFIGURE  GROUP  A  AS  SERIAL  OUTPUT  FROM  NP 

? 

CONF I G 

(•4P 

A 

{CONFIGURE  GROUP  B  AS  SERIAL  INPUT  (FLAG)  FROM  NP 

> 

CONFIG 

NP 

B 

• 

1 

{RUN  NON-RESIDENT  TASK 
RUN 

V 

{ASK  FOR  LOCAL  PROCESSING  TASK  -  SERIAL  INPUT/OUTPUl 

y 

LOCAL 
S 1 0 


{STOP  NON-RESIDENT  TASK 
5 

STOP 


Figure  62  Indirect  Comand  File  R2A.DEM 


?RUN  N0M-RESIL1ENT  TASK 

7 

RUN 

;A:;:K  for  LOCAL  PROCESSING  TASK  -  SERIAL  INPUT/OUTPUT 

7 

LCiCAL. 

SIO 

5 

;STOP  NON-RESIDENT  TASK  AND  RESET  LM 

* 

STOP 

RESET 


Figure  64  Indirect  Connand  File  R2C.DEM 
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15 


ANfi  ANfiWER  THE  QUESTIONS  ABOUT 
THE  riJR-r.TiR  HOME  UP  CONTROL  FOR  YOUR  TERMINAL 

EXAMPLE  or  CONTROL  CHARS  FOR  CURSOR  HOME  UF'  : 

AUMSA  1  CHAR  - IE 

ACT  a  1  CHAR  -  ID 

DEC  VT-52  2  CHARS  - 1B.4.S 

HAZE  1500  2  CHARS  -  7E» 12 

HARD  COPY  1  CHAR  -  00 


+t  L>l-  COMIROL  CHARS  ?  2 

ENTER  control..  CHARS  IN  HEX  ASCI  I  AS  XX,  XX 

■TELECT  QNE  of  THE  FOLLOWING  : 

■:  :  NO  transcript  ON  CRT 
:  :  DRIFF  transcript  ON  CRT 
2.  :  FULL  TRANSCRIPT  ON  CRI 


DO  YOU  WANT  TO  OPEN  A  LOG  FILE  ’•(Y/Nn^ 
open  output  log  FILE 
ENTER  FILENAME 
SFRIALTST 

$SS*  OUTPUT  LOG  FILE  "SERIALTST.LOG"  IS  OPENED  **** 

ENTER  IDENTIFICATION 
Ti-~ST  SERIAL  SUBSYSTEM 

«  « •r  «  V.  V.  fr***********^  * 

REMOTE  LINK  UNIT  DEMOSTRATION 

17:15:40  09- JAN-81 

id:  test  serial  SUBSYSTEM 

•»*•»  ^^  •»•«••»•-#**•«■»■•«■**■»***■*«**»**************•«■**■«■****«•■»•**«•■»»»*•*  •«« -H -t'-r  f 


CMLi>  (»R2A 
NPINIT 


h++4+++++H 


***♦*■«  ENTER  NPINIT  CMD  MODULE  #♦**#* 


STATUS:  FAILURE  CODE:  -10 


+++++++ 


H-  +  -I  +4-+4++  +  -! 


Figure  65  (•)  Display  on  CRT  #1 
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CMLO  eR2A 
NPINIT 

-t  ^-++++■^++^-^-++++++++++•♦-+++^-^-++-«-++++•*■++ 

<***«#  ENTER  NPINIT  CMD  MODULE  ****** 

IMP  DIAGNOSTIC  RESULT  : 

«*  DIAGNOSTIC  COMPLETED 
41  OF  FREE  RECORDS  =  S 


STATUS:  SUCCE 

4-  +++  +  4  +  +++  ++4 

PRGMLD 


******  ENTER  PROMLD  CMD  MODULE  ****** 

DATA  I/O  (DIO)  OR  SUBSYSTEM  DIAGNOSTIC  (SSD)  ? 
DIO 

FROM  LMG  OR  NP  ? 

NP 


status:  SUCCESS 

+  +  + 4-  +  +++H'  +  ‘+'  +  +  4  44  "♦“4+444  ' 

CONF I G 

+  +  +  4-  4 1 

******  ENTER  CONFIG  CMD  MODULE  ****** 


FROM  LMG  OR  NP  ? 
NP 

GROUP  A  OR  B  ? 

A 


STATUS :  SUCCESS 

4-4-4-  +  4-+4 

CONFIG 

4- 4- 4- 4- 4- 4-4 

******  enter  CONFIG  CMD  MODULE  ****** 


FROM  LMG  OR  NP  ? 
NP 

GROUP  A  OR  B  ? 

B 


STATUS:  SUCCESS 

4-4- 

RUN 
+  +  +  ' 

******  ENTER  RUN  CMD  MODULE  ****** 


STATUS:  SUCCESS 

4-4 

LOCAL 


Figure  65  (b)  Display  on  CRT 


SELECT 

ONE  OF  THE 

DATA  TRANSFER  ROUTINES  : 

REF  IN 

ALOIN 

SYNIN  SINREF 

S AMD IN 

DINMOF 

SECIN 

S INF LG 

D I NMOL 

SEi  lOUT 

ALGOUT 

SYNOUT  DISOUT 

SOUTA 

SOUTB 

SYNIU 

SIO 

CRTS I M 

SIO 


tn.>  +•  00  =  oc>oc> 

Qo  V  04  =  0036 

09  I  0^  =  0013 


<  SLtPSYSTEM  DOWN  > 

STOP 

enter  stop  cmd  module  ♦***♦* 


statue:  failure 

+  +  H”-h‘1'  +  +  +  +  +  *H-H 


code:  -11 


Figure  65  Cb)  (Continued) 


B 


Xf--RTE<L 

+  -f'+4’-(  H- +  +  +  +  +  +  + •+  +  +  +  4‘ +  +  +  +  +  +  +•+  +  •+ +4  44*444 44*4'4+  +4  44444444444-444444  4  444444  444'^44444-1- 

enter  xfrtbl  cmd  module  #*■»**» 

TABLE  NAME  ? 

NPRE.:: 

F.TAD  OR  WRITE  (R/W)  ? 

W 

RECOFvD  FUNCTION  (0  -  5) 

0  r  WRTREC  1  :  EOD 

2  :  BOD  3  :  BACREC 

^  :  rWDREC  5  :  ERAWRT 


*»  OF  RECORDS  (1  -  IS) 


STATUS;  SUCCESS 
XFRTBL 

+++++++++++++++++++++++ 

******  enter  xfrtbl  CMD  MODULE  ****** 


-i-4+  +  +  +  +++++-«  +  +++++ 

r++++  +  +  +  +  +  4  + 


TABLE  NAME  ? 

NF'REC 

READ  OR  WRITE  <R/W)  ? 
R 

#  OF  RECORDS  <1  -  3) 

1 


3A  07  09  00  IS  05  07  FF  FF  FF  FF  FF  FF  FF  99  FF 

RECORD  ID  CODE  :  3A 

SUBSYSTEM  FAILURE  DETECTED 
#  OF  VALID  BYTES  *  7 

date;  JAN  9  <  JAN  9  FOR  LEAP  YEAR) 
time:  18  :  5  (HOUR: MINUTE ) 


Figure  65  (c)  Display  on  CRT  ll 


E 


L  md: 

tv  UN 

j -(s «•  *.  f::r'!Ttri’‘  rijn  cmh  i^CjDUll'  »•»**• 


■  -i  f -* -(  -•  H  ->  -f  -i  ••.  -I  H-+-t-T 


rTAlIJS:  :?.UCCf:St 

+  V  -H-+H-H  ^  +^  V  i  +H  4  4 +V  +4 -!-++•+ ^■  T^■^-  +  +  +  +  ^-+  +  +  V-  +  ^ +  +  +  +  +  +  ++  +  ■+ +-(-■ 

LOCAL 


SFLLCT  CNF  OF  THF  DATA  TRANSFER  ROUTINEr?  : 


FVFFIK  ALCIN  SYNIN 

vr.'''lN  ••3k'l-LO  D I  NMOL 

CL-OOIJT  mLOOIJT  SYNOLIT  DISOUT 

CYNIC  CIO  CRTCIM 


SINREF  3 AMD IN  DINMOF 

SOUTA  SOUTB 


1 0 


f.- 

»*.  ‘ 
1%' 


li 


,,(;i  +  oc  =  0000 

(1)0  *  04 
STOP 

ENTER  STOP  CMD  MODULE  #*#*»* 


I-4-  +  +  4-4-4- 


STATUS:  SLlCCESS 

4-4- 4-4- 4-4-4  4-4  4  +  H 

RESET 

4-444  +  444-4  t-H 

#*•!>■■»»*  ENTER  RESET  CMD  MODULE  ■«»■***** 


STATUS:  SUCCESS 

4-  +  +  +  4'  +  - 


^+++44  +  +++4-44+4  +4 


M-  +  +  4+  +  +  +  +  4-4+4  +4  4 


H*  +  H-  ^  +  4- t  +  4*  4-  4-  + 


R-f  4-4  4*4-4- 4* 


CMD>  E 

END  OF  DEMONSTRATION 

•»■***•»**■»**«•»*#***********••<•***♦***«  *«#*****♦« *  •*  -K  4!  •»  *■»•* 

TT7  —  STOP 


Figure  (d)  Display  on  CRT  #1 
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Figure  66  (a)  SM  Display  on  CRT  #2 
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Figure  66  (b)  SM  Display  on  CRT  #2 
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Figure  66  (c)  SM  Display  on  CRT  #2 


cords.  The  Data  I/O  task  Is  uploaded  from  the  MP.  Group  A  and  Group  B  of 
the  ICA  are  both  configured  from  the  MP.  The  nonresident  data  1/0  task  Is 
executed  by  the  RUN  command.  The  LOCAL  command  offers  a  choice  of  data 
transfer  routines.  In  this  example,  the  serial  I/O  (SIO)  data  transfer 
routine  Is  selected.  Two  numbers,  an  operator,  and  the  result  are  trans¬ 
ferred  to  the  LMG  and  displayed  on  the  CRT  when  the  subsystem  flag  Is 
raised.  For  example,  the  first  data  transfer  Is  displayed  on  CRT  #1  as 
09*04^0036.  At  the  same  time,  referring  to  Figure  66  (b),  we  can  see 
these  data  In  the  Input  buffer  (I/O  Buffer  1) 

Now  we  change  the  transmission  parity  of  the  subsystem.  A  'subsystem 
down'  message  Is  shown  on  CRT  #1  and  the  data  I/O  task  stops  running. 
Therefore,  the  STOP  command  gets  return  status  failure  code  -11.  This 
failure  code  means  that  the  nonresident  task  had  already  stopped  running. 
This  same  condition  can  be  seen  at  CRT  #2  as  shown  In  Figure  66  (c). 

In  Figure  65(c),  @R2B  Is  Issued  to  examine  the  time  and  cause  of  the 
subsystem  failure. 

In  Figure  65  (d) ,  @R2C  Is  Issued  after  correcting  the  errors  that 
caused  the  subsystem  failure.  The  Data  I/O  task  restarts  and  the  local 
processing  routine  performs  the  data  transfers.  At  the  end  of  the  demon¬ 
stration,  we  stop  the  data  I/O  task  and  reset  the  ICA  configuration.  The 
E(EXIT)  command  Is  used  to  end  the  demonstration. 


SECTION  6 


SUBSYSTEMS 


Subsystems  are  peripheral  components  that  can  be  Interfaced  to  an 
avionic  system  through  an  LM.  Two  subsystems  have  been  designed  for  the 
RLU  demonstration:  a  serial  subsystem  and  a  synchro  subsystem.  The  former 
sends  and  receives  serial  data,  while  the  latter  handles  analog  data  In  the 
form  of  synchro  voltages.  Attached  to  each  subsystem  Is  a  nameplate  which 
holds  data  pertaining  to  Its  subsystem.  When  the  LM  Is  connected  to  a  sub¬ 
system,  It  must  be  appropriately  configured  to  be  able  to  successfully 
transfer  data.  The  ICA  configuration  required  for  a  subsystem  Is  stored  In 
the  subsystem's  nameplate. 

Each  subsystem  has  programs  stored  in  Its  nameplate  which  will  run  In 
the  LM  when  the  subsystem  Is  connected.  Each  program  enables  data  to  be 
Input  from  the  subsystem,  performs  certain  operations  on  the  data,  and  then 
outputs  the  processed  data  to  the  subsystem. 

Discussion  of  the  design  of  each  subsystem  requires  that  three  impor¬ 
tant  aspects  be  considered:  the  hardware  of  the  subsystem,  the  related 
software  necessary,  and  the  data  stored  in  the  corresponding  nameplate. 

This  section  will  discuss  these  three  aspects  for  both  the  serial  and  syn¬ 
chro  subsystems. 

6.1  SERIAL  SUBSYSTEM 

This  subsystem  Is  capable  of  transmitting  three  8  bit  bytes  as  serial 
data  to  the  LM.  It  can  also  receive  and  display  two  8  bit  bytes  from  the 
LM  as  serial  data.  The  data  to  be  transmitted  can  be  set  through  thumbwheel 
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switches.  The  subsystem  generates  a  parity  bit  for  every  byte  of  data  to 
be  transmitted  and  is  capable  of  performing  a  parity  check  on  data  received. 
The  data  transfers  are  synchronous  with  the  clock  being  provided  by  the  LM. 

Demonstration  of  the  serial  subsystem  takes  place  by  using  the  sub¬ 
system  as  a  calculator  that  performs  additions  and  multiplications  on 
double-BCD-dlglt  operands.  Of  the  three  bytes  transmitted  by  the  subsystem, 
the  first  and  third  bytes  define  the  double-BCD-dlglt  operands,  while  the 
second  byte  defines  the  operation.  The  LM  performs  the  operation  and  pro¬ 
duces  a  four-BCD-dlgit  result.  This  result  (two  bytes)  is  then  transmitted 
by  the  LM  and  received  and  displayed  by  the  subsystem. 

6.1.1  HARDWARE  DESIGN 

The  subsystem  consists  of  two  sections:  the  sending  subsystem, 
and  the  receiving  subsystem.  The  sending  subsystem  can  operate  In  two 
modes  -  flag  or  refresh.  In  the  flag  mode  data  Is  transmitted  only  when 
the  STBSW  switch  on  the  panel  Is  closed.  Prior  to  closure  of  STBSW  the 
value  of  the  thumbwheel  switches  can  be  set.  On  closure  of  STBSW,  data  on 
the  thumbwheel  switches  Is  latched  until  either  the  transmission  Is  success¬ 
ful,  or  the  RESET  switch  on  the  panel  Is  closed.  In  the  refresh  mode  data 
Is  transmitted  as  soon  as  It  Is  requested  by  the  LM.  Data  Is  latched  only 
as  long  as  the  transmission  takes  places.  Changes  on  the  thumbwheel 
switches  are  detected  during  the  periodic  transmission  cycles  Initiated  by 
the  LM. 

The  block  diagram  of  the  sending  subsystem  Is  shown  In  Figure  67. 

A  detailed  drawing  of  this  circuit  is  presented  In  Appendix  B,  Section  6-A. 
block  diagram  there  are  two  Inputs  REQ/LOK  and  SCLK  from  the  ICA  and  two 
outputs  SDATA  and  FLG/ACK  to  the  ICA.  The  ICA  requests  transmission  by 
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Diagram  of  Serial  Sending  Subsystem 


raising  the  REQ/LOK  line.  If  MODSW  is  in  the  refresh  node  the  control  logic 
immediately  responds  by  raising  the  FLG/ACK  line.  If  MODSW  is  in  '.he  flag 
mode,  the  control  logic  will  raise  FLG/ACK  only  when  STBSW  is  closed.  When 
FLG/ACK  goes  high  the  data  on  the  thumbwheel  switches  is  latched  into  the 
data  latches  by  LOCKOUT. 

When  the  ICA  sees  FLG/ACK  high,  it  sends  the  clock  pulses  on 
SCLK.  The  control  logic  uses  SCLK  to  generate  BITCOUNT  and  'WORDSELECT' . 
Depending  on  'WORDSELECT'  an  8  bit  byte  is  selected  from  the  outputs  of  one 
of  the  three  latches.  'BITCOUNT*  determines  which  bit  of  this  byte  is  to 
be  transmitted.  That  bit  is  output  from  the  parallel  to  serial  converter. 
When  the  bit  count  goes  to  9  the  parity  generator  transmits  the  parity  bit 
in  accordance  with  the  PARITY  selector  switch.  When  3  bytes  have  been 
transmitted  either  of  two  things  may  happen  depending  on  the  mode.  In  the 
refresh  mode  the  last  clock  pulse  goes  low  and  then  REQ/LOK  goes  low.  This 
sets  LOCKOUT  low  and  the  data  is  no  longer  latched.  On  the  other  hand,  in 
the  flag  mode  LOCKOUT  needs  to  be  high  if  the  transmission  was  unsuccessful. 
To  keep  LOCKOUT  high  the  ICA  brings  REQ/LOK  low  first,  and  then  brings  the 
last  clock  pulse  low.  This  keeps  the  old  data  latched.  If  the  transmission 
was  successful  in  the  flag  mode  then  the  ICA  brings  the  last  clock  pulse 
low  and  then  brings  REQ/LOK  low  (similar  to  the  refresh  mode) .  LOCKOUT  can 
be  set  low  also  by  closing  RESET. 

The  second  section  of  the  hardware  is  the  receiving  subsystem. 

The  block  diagram  for  the  receiving  subsystem  is  shown  in  Figure  68.  A 
detailed  drawing  of  this  circuit  is  presented  in  Appendix  b.  Section  6-A.  As 
shown  in  the  block  diagram,  there  are  3  input  lines  SDATA,  SCLK,  and  REQ/LOK 
from  the  ICA  and  one  output  line  FLG/ACK  to  the  ICA.  When  the  ICA  wants  to 


Figure  68  Block  Diagram  of  Serial  Receiving  Subsystem 


display  serial  data  It  sets  the  REQ/LOK  line  high.  The  control  logic  In- 
medlately  responds  by  setting  the  FLG/ACK  line  high.  When  the  ICA  detects 
that  the  FLG/ACK  line  is  high  it  starts  sending  the  clock  pulses  on  SCLK 
and  simultaneously  sends  data  on  SDATA. 

The  serial  to  parallel  conversion  block  accumulates  9  serial  bits 
with  the  help  of  the  clock  (SCLK)  and  sends  them  to  the  parity  error  detect 
block.  It  also  supplies  the  display  with  the  8  data  bits.  At  the  end  of 
9  bits  WORDSTROBE  goes  high  which  allows  the  parity  error  detect  block  to 
determine  if  there  was  a  parity  error  in  accordance  with  the  parity  select 
switch.  Also  WORDCOUNT  Increments  and  enables  the  display  to  latch  onto 
the  8  bits  and  causes  the  data  to  be  displayed.  If  there  is  a  parity  error, 
ERROR  will  go  high  and  the  control  logic  will  set  FLG/ACK  low,  which  will 
stop  the  transmission.  Also  the  line  to  the  RX  parity  error  LED  will  go 

high  and  light  the  LED.  If  no  error  occurs,  at  the  end  of  the  next  9  bits 

the  cycle  will  be  repeated. 

For  the  subsystem  to  function  properly  it  must  have  the  sending 
subsystem  connected  to  one  group  of  the  ICA  and  the  receiving  subsystem  to 

the  other  group  of  the  ICA.  The  connections  to  the  LM  are  made  through 

the  4  I/O  lines  at  the  buffers  of  each  subsystem. 

6.1.2  SOFTWARE  DESIGN 

For  the  subsystem  to  function  as  a  calculator  there  needs  to  be 
a  software  program  running  in  the  LM  to  perform  the  calculations.  This 
program  is  stored  in  the  nameplate  of  the  subsystem  and  runs  in  the  LM  as 
a  nonresident  task. 

A  broad  picture  of  the  processing  performed  by  this  program  is 
given  in  Figure  69  .  A  detailed  description  of  the  program,  subroutines 


220 


COMMENTS 


Set  SM 


2. 

bcp  6|i«r».»u)(s 
1  kj-te 
epereUruK. 


ptr^rm 

t'tSBii-  tK 
Bc.t> 


Figure  69  Serial  I/O  Program 


used,  and  common  data  referenced,  appears  in  Appendix  C,  Section  6-A.  The  ini¬ 
tialization  procedure  consists  of  setting  up  the  shared  memory  flags  for 
receiving  data.  Once  this  is  performed  the  program  attenqits  to  input  data 
from  the  subsystem  through  the  IGA,  which  must  be  configured  properly  prior 
to  running  the  program.  If  the  input  procedure  is  successful,  the  program 
will  have  three  bytes  of  BCD  data.  The  second  byte  defines  operation:  add 
or  multiply,  while  the  first  and  third  bytes  define  the  operands.  The  pro¬ 
gram  proceeds  to  implement  the  operation  by  calling  the  math  service  of  the 
executive.  First  the  BCD  operands  will  be  converted  to  binary  and  then  the 
operation  will  be  performed.  The  result  of  the  operation  Is  finally  con¬ 
verted  to  4  BCD  digits.  This  result  Is  output  back  to  the  subsystem  through 
the  ICA.  If  the  output  procedure  Is  successful,  the  program  transfers  the 
input  and  the  output  bytes  to  the  data  buffer  In  shared  memory. 

If  an  error  occurs  during  input  or  output  transmission,  the  pro¬ 
gram  will  immediately  write  a  failure  record  into  the  subsystem's  nameplate. 
The  record  will  contain  the  time  of  failure  and  the  error  type.  Conse¬ 
quently  the  program  will  stop  execution. 

For  this  subsystem  the  ICA  needs  to  be  configured  as  follows: 

Group  A  -  serial  output.  Group  B  -  serial  input  (flag  mode).  The  seven 
configuration  bytes  for  each  group  are  in  the  nameplate  and  it  is  the  duty 
of  the  coimiand  interpreter  to  configure  the  ICA  with  these  bytes,  upon  re¬ 
ceiving  the  appropriate  comnand. 

For  a  detailed  description  of  the  program  refer  to  Appendix 
C,  Section  6-A. 

6.1.3  NAMEPLATE  DATA 

As  was  mentioned  earlier,  the  nameplate  holds  the  ICA  configura- 
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tlon  bytes  and  the  software  program  required  by  the  subsystem  to  %^lch  it 
Is  attached.  The  ICA  configuration  consists  of  7  bytes  for  each  group  of 
the  ICA,  totaling  14  bytes  in  all.  The  software  program  for  the  serial 
subsystem  consists  of  a  total  of  959  bytes.  The  header  for  this  program  Is 
also  present  In  the  nameplate  and  consists  of  13  bytes.  Lastly  there  is  a 
checksum  byte  at  the  end  of  the  program.  A  map  depicting  how  these  elements 
are  stored  in  the  nameplate  is  shown  in  Figure  70. 

If  an  error  occurs  during  an  input  or  an  output  request  of  the 
subsystem  program,  a  failure  record  is  written  into  the  nameplate.  Figure 
48  shows  the  contents  of  a  typical  failure  record. 

6.2  SYNCHRO  SUBSYSTEM 

The  synchro  subsystem  consists  of  an  enclosure  with  two  synchros.  In 
this  subsystem,  one  of  the  synchros  operates  as  an  input  device  while  the 
other  operates  as  an  output  device.  The  angle  of  the  output  synchro  is 
Incremented  by  the  angle  of  the  input  synchro  periodically.  This  results 
in  a  rotational  motion  of  the  output  dial.  The  Increments  are  made  in  3 
second  Intervals  in  order  to  meet  the  response-time  limitations  of  the 
synchro.  The  value  of  each  angle  is  measured  (input)  or  controlled  (output) 
in  terms  of  three  synchro  voltages  associated  with  the  angle. 

6.2.1  HARDWARE  DESIGN 

The  hardware  of  this  subsystem  consists  of  two  synchros.  It  also 
contains  certain  connections  to  the  synchro  windings  which  enable  the  syn¬ 
chros  to  operate  properly. 

The  synchros  used  in  the  implementation  have  windings  with  the 
configuration  shown  In  Figure  71(a).  Such  a  winding  configuration  charac- 


terlzes  a  differential  synchro,  which  is  not  suitable  for  this  application. 
What  is  desired  is  a  transmitter  synchro  with  windings  in  the  form  shown  in 
Figure  71  (b).  Also,  the  voltages  supplied  to  or  sensed  from  the  stator 
windings  should  correspond  to  phase  voltages.  However,  the  synchro  stator 
does  not  have  an  accessible  ground  connection.  Therefore  a  ground  is 
created  through  a  resistor  network  between  the  windings.  These  modifications 
are  shown  in  Figure  71  (c)  which  shows  a  winding  wiring  which  is  equivalent 
to  the  synchro  shown  in  Figure  71(b).  The  capacitor  between  the  two  rotor 
windings  is  used  to  reduce  the  power  factor  of  the  windings. 

6.2.2  SOFTWARE  DESIGN 

As  mentioned  earlier,  to  demonstrate  the  functioning  of  the  sub¬ 
system,  the  angle  of  the  output  synchro  is  Incremented  periodically  every 
3  seconds.  The  value  of  each  Increment  is  determined  by  the  angle  set  on 
the  input  synchro.  To  perform  this  demonstration  a  software  program  must 
run  in  the  LM.  This  program  is  stored  in  the  electronic  nameplate  and  is 
loaded  into  the  LM  as  a  nonresident  task. 

A  broad  picture  of  the  processing  performed  by  this  program  is 
given  in  Figure  72.  A  detailed  description  of  the  program,  subroutines 
used,  and  coranon  data  referenced,  appears  in  Appendix  c.  Section  6-B.  The  Ini¬ 
tialization  procedure  consists  of  setting  up  the  shared  memory  flags  for 
receiving  data  and  initializing  the  ICA  for  synchro  operation.  Once  this 
is  done  the  program  inputs  the  three  synchro  voltages  of  the  input  synchro 
through  the  ICA.  The  voltages  are  input  in  the  form  of  three  single  byte 
binary  values  of  an  ADC.  The  three  voltages  are  tested  to  determine  if 
the  synchro  is  malfunctioning  or  not.  The  first  test  checks  if  the  sum 
of  the  three  voltages  is  zero.  The  second  test  calculates  the  value  of 
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the  synchro  constant  'A*  by  calling  upon  the  executives  math  service,  and 
compares  It  with  the  nominal  value.  If  the  voltages  fall  any  of  these 
tests,  the  program  writes  a  failure  record  Into  the  subsystems  nameplate 
and  exits.  A  typical  failure  record  is  shown  in  Figure  48  . 

If  the  tests  are  successful,  the  program  determines  the  input 
synchro  angle  from  the  three  voltages  by  using  the  math  service  of  the 
executive.  It  then  adds  this  angle  to  the  previous  angle  of  the  output 
synchro.  Next  It  uses  the  executive's  math  service  again  to  determine  the 
three  synchro  voltages  corresponding  to  the  resulting  output  angle.  Finally 
the  program  outputs  the  three  synchro  voltages  to  the  output  synchro,  writes 
the  input  and  output  angles  Into  SM,  and  waits  for  3  seconds  before  It 
repeats  the  procedure. 

6,2.3  NAMEPLATE  DATA 

The  nameplate  holds  the  ICA  configuration  bytes  and  the  software 
program  required  by  the  subsystem.  The  configuration  is  7  bytes  for  each 
group  -  14  bytes  In  all.  The  software  program  for  the  synchro  subsystem 
consists  of  1061  bytes.  The  header  for  the  program  Is  also  in  the  nameplate 
and  consists  of  13  bytes.  A  map  depicting  how  these  elements  are  stored  In 
the  nameplate  Is  shown  In  Figure  73  . 
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Figure  73  Map  of  Nameplate  Data  for  Synchro  Subsystem 
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modes  -  flag  or  refresh.  In  the  flag  mode  data  is  transmitted  only  when 
the  STBSW  switch  on  the  panel  is  closed.  Prior  to  closure  of  STBSW  the 
value  of  the  thumbwheel  switches  can  be  set.  On  closure  of  STBSW,  data  on 
the  thumbwheel  switches  is  latched  until  either  the  transmission  is  success 
ful,  or  the  RESET  switch  on  the  panel  is  closed.  In  the  refresh  mode  data 
is  transmitted  as  soon  as  it  is  requested  by  the  LM.  Data  is  latched  only 
as  long  as  the  transmission  takes  places.  Changes  on  the  thumbwheel 
switches  are  detected  during  the  periodic  transmission  cycles  Initiated  by 


the  LM. 


The  block  diagram  of  the  sending  subsystem  is  shown  in  Figure  67. 
A  detailed  drawing  of  this  circuit  la  presented  in  Appendix  B,  Section  6-A. 
block  diagram  there  are  two  inputs  REQ/LOK  and  SCLK  from  the  ICA  and  two 
outputs  SOATA  and  FLG/ACK  to  the  ICA.  The  ICA  requests  transmission  by 


